In order to provide more details context of how client arrived at the unsafe
page, particularly in redirect case, we may have to add more information to
redirect chains including:
- referrer (if any)
- remote address.
- URL
We may want to use an idl interface instead of nsIPrincipal to store these
information
MozReview-Commit-ID: 3Uh4r06w60C
- The profiler gives the JS engine a reference to the pseudo-stack via
SetContextProfiilngStack(). That function now takes a |PseudoStack*| instead
of a |ProfileEntry*| and pointer to the stack pointer.
- PseudoStack now has a |kMaxEntries| field, which is easier to work with than
|mozilla::ArrayLength(entries)|.
- AddressOfStackPointer() is no longer needed.
- The patch also neatens up the push operations significantly. PseudoStack now
has pushCppFrame() and pushJsFrame(), which nicely encapsulate the two main
cases. These delegate to the updated initCppFrame() and initJsFrame()
functions in ProfileEntry.
- Renames max_stck in testProfileStrings.cpp as peakStackPointer, which is a
clearer name.
- Removes a couple of checks from testProfileStrings.cpp. These checks made
sense when the pseudo-stack was accessed via raw manipulation, but are not
applicable now because we can't artificially limit the maximum stack size so
easily.
This includes renaming its fields to match SpiderMonkey naming conventions
instead of Gecko naming conventions.
This patch is just about moving the code. The next patch will change
SpiderMonkey to actually use PseudoStack directly.
--HG--
extra : rebase_source : 27e77ddf950201eb6bdba60003218056442cf7ab
Add event listeners and implement basic messages between chrome and
content so let e10s content in GeckoView request/exit fullscreen. Once
we're on the parent side, we still go through the normal fullscreen flow
so there is no platform or Java change involved.
MozReview-Commit-ID: G1tBIOoFqkB
Now that GeckoInterface only contains openUriExternal and
getHandlersFor* methods, we can set GeckoInterface from GeckoApplication
only, and not GeckoApp or GeckoView. This also lets us get rid of
BaseGeckoInterface.
MozReview-Commit-ID: KQloIO6ITlK
ViERenderer is not used anywhere but has a couple calls to the obsolete
GeckoAppShell orientation listener. The entire ViERenderer.java file is
getting removed in the upcoming WebRTC update, so we should just go
ahead and remove those lines.
MozReview-Commit-ID: AwG7dBg5MV8
Remove GeckoAppShell.AppStateListener and its associated methods in
GeckoInterface (orientation listener and app state listener methods).
MozReview-Commit-ID: 4BCrTysSEHZ
Add configurations for building and uploading AArch64 Nightly builds, in
tier 1 and without artifact support for now.
As for not denoting AArch64 builds as "api-21", I don't really think we
will split AArch64 the way we split ARMv7 before. Originally, we split
into API 9 and API 11+ because of lots of "constrained" devices that
were stuck with API 9. We made an API 9 APK in order to lower our
footprint on those devices. That probably will not be a problem for
AArch64, because devices with API 21+ and AArch64 support are usually
more than capable for running Fennec. Secondly, it was a big change for
Android going from API 9 to API 11+, so we saved quite a bit of
code/resources when we stripped out API 11+. I don't see such drastic
changes going from API 21 to upcoming versions, so even if we did split,
I don't think it'll get us much benefit.
MozReview-Commit-ID: 7N7Slv1pPgb
I confirmed that the test crashes in the crashtest harness without the
patch (although the harness doesn't exit!), whereas it passes with the
patch.
MozReview-Commit-ID: 37S6i1kvw37
--HG--
extra : transplant_source : %9F%A91%90%3F%93%1F%E5%B3%ACHf%8C%BD%BA%C9%12%97%83I
The openssl.org webpage has been reorganized and the old URL no longer works.
Source-Repo: https://github.com/servo/servo
Source-Revision: 83f82cb4d380f2bdd02f388702d6162af9a3c9bc
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : f4f5a984196edb87c05c9e382989013bc363550c
With these changes the latest update in updates.xml is always the latest update in progress even before applying the update. This makes it so that after a successful update the code in nsBrowserContentHandler.js will always get the correct custom update property.
