This is a large refactoring of the DocumentChannel process switch codepath,
with the end goal of being better able to support future process switch
requirements such as dynamic isolation on android, as well as the immediate
requirement of null principal handling.
The major changes include:
1. The logic is in C++ and has less failure cases, meaning it should be harder
for us to error out unexpectedly and not process switch.
2. Process selection decisions are more explicit, and tend to rely less on
state such as the current remoteType when possible. This makes reasoning
about where a specific load will complete easier.
3. Additional checks are made after a "WebContent" behavior is selected to
ensure that if an existing document in the same BCG is found, the load will
finish in the required content process. This should make dynamic checks such
as Android's logged-in site isolation easier to implement.
4. ProcessIsolation logging is split out from DocumentChannel so that it's
easier to log just the information related to process selection when
debugging.
5. Null result principal precursors are considered when performing process
selection.
Other uses of E10SUtils for process selection have not yet been migrated to the
new design as they have slightly different requirements. This will be done in
follow-up bugs.
Differential Revision: https://phabricator.services.mozilla.com/D120673
There are races which are more common after these patches where an implicit
about:blank load races with a speculative parent process load's process switch.
In this situation, bad behaviour can result as we process a navigation started
by a process which we process-switched away from. By tracking the explicit
ContentParent which is making the DocumentLoadListener request, we can catch
situations like this and avoid navigations being started from the wrong
processes.
Differential Revision: https://phabricator.services.mozilla.com/D120672
After the changes in this bug, about:blank loads triggered by chrome will
finish in a "web" content process, as they have an untrusted null principal
without a precursor. In a few places throughout the codebase, however, we
perform about:blank loads with the explicit expectation that they do not change
processes. This new remoteTypeOverride option allows the intended final process
to be explicitly specified in this situation.
For security & simplicity reasons, this new attribute is limited to only be
usable on system-principal triggered loads of about:blank in toplevel browsing
contexts.
Differential Revision: https://phabricator.services.mozilla.com/D120671
As it's usually not very useful. I don't know how easily we can add a
reliable test for this, let me know if you come up with an idea to do
that.
Differential Revision: https://phabricator.services.mozilla.com/D122222
This patch introduces a new type alias OkOrErr for Result<Ok, QMResult> and also converts some existing occurencies of Result<Ok, QMResult> to OkOrErr.
Differential Revision: https://phabricator.services.mozilla.com/D122206
On PowerVR devices we have seen reports of red lines and shapes
appearing randomly on the screen. What is happening is that clip masks
are being rendered in to the RGBA8 texture atlases that were the
previous pass' target, rather than the current R8 render target. Red
shapes therefore appear on top of the cached items in the RGBA texture
atlases, and parts of these subsequently get rendered to picture cache
tiles then the screen.
This appears to be due a bug with glInvalidateFramebuffer. We call
this function once we have finished using a render target for the
frame (ie we have rendered all items which need a clip mask). But
presumably, due to the asynchronicity of OpenGL, the draw calls to
render the clip masks to the render target are in fact still pending
at this point. Perhaps the driver incorrectly recycles the render
target's memory too early, and as a result the masks get written to
the wrong texture.
This patch therefore omits the calls to glInvalidateFramebuffer on
PowerVR devices. While this bug has been hard to reproduce reliably,
it appears to solve the issue.
Differential Revision: https://phabricator.services.mozilla.com/D122221
The SSE flags override must be sure to reset the SSE flags first, for
reasons already stated in the code. But if multiple flags are present
the semantics of the flag overrides is a little opaque. We clean this
up.
Cleanup turns out to be not straightforward due to an existing latent
bug: in the presence of parallel compiles and SSE flags overrides the
flag computations can become racy. We fix this here by forcing an
early computation of the flags and verifying that the flags are
computed before we spawn multiple threads.
There is a minor semantic change here in that the most restrictive
setting is now kept, while previously the last setting was kept, and
this was (given the structure of the calling code) always the least
restrictive setting. In practical terms this should not matter, and
if it does we can fix fallout later.
Differential Revision: https://phabricator.services.mozilla.com/D121953
The new tests in testing/xpcshell/example/ cover the following scenarios:
- Local AND remote xpcshell tests. In contrast, modifications to
selftest.py in bug 1635227 only covered runxpcshelltests.
- `prefs=` inheritance from ancestor manifests as implemented by
https://hg.mozilla.org/mozilla-central/rev/ac51a01611dc
- Per-file `prefs` setters (used in bug 1638099).
- Multiple prefs and comments per `prefs` line.
Differential Revision: https://phabricator.services.mozilla.com/D121632
This patch swaps out the nsCollation for the mozilla::intl::Collator. Note how
the options bag is now opinionated towards ECMA-402's Intl.Collator.
Differential Revision: https://phabricator.services.mozilla.com/D120526
This patch attempts to directly wire the Intl.Collator implementation to the
mozilla::intl::Collator::Options bag. The only complexity that wasn't factored
out was the use of the locale keywords, which would invalidate the locale in
the current implementation.
Differential Revision: https://phabricator.services.mozilla.com/D120904
SpiderMonkey requires the BCP 47 locale extensions, which involves iterating
over the keywords in ICU, and mapping them to the BCP 47 version. Specifically,
this will change the "phonebook" keyword to "phonebk". This should hopefully
expose a simpler API to SpiderMonkey, the only consumer.
Differential Revision: https://phabricator.services.mozilla.com/D120903
This collator attempts to match the options bag from the Intl.Collator API
from ECMA-402. It is built to be compatible and consistent across both Gecko
code and SpiderMonkey code. Its behavior is designed to match ECMA-402.
Differential Revision: https://phabricator.services.mozilla.com/D120494
Some addons may not include an icon (e.g. static themes addons) and so the abuse report panel should
fallback to the extensionGeneric.svg.
Falling back to the extensionGeneric.svg is also needed to prevent a diagnostic crash triggered by
loading non existing resources while running the abuse report mochitests.
Differential Revision: https://phabricator.services.mozilla.com/D122207
If `isFieldInit()` returns `true`, the first `if`-statement is taken, so it must
be `false` in the `else` block.
Depends on D121746
Differential Revision: https://phabricator.services.mozilla.com/D121747
While removing unnecessary `mozilla::Maybe` in the last part, I've noticed that
this header has many unused or unnecessary includes.
Depends on D121743
Differential Revision: https://phabricator.services.mozilla.com/D121745
Source positions used `mozilla::Maybe<uint32_t>` for BinAST, but with BinAST
removed, we can now change this back to use `uint32_t`.
Depends on D121742
Differential Revision: https://phabricator.services.mozilla.com/D121743
We could optimise this case by not popping `CTOR` from the stack in
`emitPrivateStaticMethod`, but that requires more changes in `PropertyEmitter`.
Depends on D121739
Differential Revision: https://phabricator.services.mozilla.com/D121740
