The changes in the previous part had a few behaviour changes which are visible
in tests, including cross-origin iframes with sandboxed origins now loading
remotely, and process selection for chrome-triggered null principal loads
behaving differently. In general this caused more process switches.
Differential Revision: https://phabricator.services.mozilla.com/D120674
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
It's non WebRender specific, so it will not be a problem on Fission,
additionally it's not used on non WebRender with retained display stuff
either.
Differential Revision: https://phabricator.services.mozilla.com/D121929
Changed the browser and mochitest name tests to rely exclusively on name change
events. To make this happen, I fixed all the cases where we were
event-deficient in the code:
* Examine target in PushNameOrDescriptionChange if it has eNameFromSubtreeRule.
Fixes cases where a text change event happens with the subtree name root as target.
* Change in aria-labelledby should always result in a name change event because
that attribute has highest prescedence.
* Add eHasNameDependent/eHasDescriptionDependent context flags when dependee accessible
is added after dependent accessible to tree.
* Handle value attribute change in HTML buttons and determine if they should trigger a
name changed event.
* Use accessible tree instead of content tree when calculating HTMLSelectOptionAccessible
name, this keeps the PushNameOrDescriptionChange sees in name flags consistent with
the actual tree.
* Handle label attribute change in select options and determine if they should trigger
a name changed event.
* Determine if s summary attribute change on a table triggers a name change event.
* If a title attribute is changed, reliably fire a name change event if
it is used in name calculation.
Differential Revision: https://phabricator.services.mozilla.com/D121580
Without this change, the initialized changes cause failures around
crashed tabs, as the `frameLoader.browsingContext` getter returns null
after the tab has crashed due to being unable to start a new remote
browser or docshell using the same browsingContext.
The new behaviour avoids creating duplicate hosts for a given
BrowsingContext by instead returning the existing potentially-discarded
browsingContext in these situations.
Depends on D121689
Differential Revision: https://phabricator.services.mozilla.com/D121891
I'm unsure if this is the cause of our crashes, but there is a chance that we
are somehow attempting to re-initialize a nsFrameLoader after it has been
destroyed, and thus re-connecting to a process which has has an
already-destroyed browser. This adds a flag to prevent initialization from
being attempted multiple times for a nsFrameLoader.
Differential Revision: https://phabricator.services.mozilla.com/D121688
This should hopefully make it easier to figure out the cause of future crashes
from this assertion by including slightly more information in the crash
message. This should be helpful if the changes in part 2 don't end up fixing
the underlying issue.
Differential Revision: https://phabricator.services.mozilla.com/D121687
I don't see why we would want this to go away. The slow script warning is going
to continue to exist, and I think it's unlikely that we won't ever make changes
to its logic, so it makes sense to continue monitoring it.
Differential Revision: https://phabricator.services.mozilla.com/D121553
On Android, Windows and my local Linux machine, the height of
`.flexbox > label` in the reference is 0.5px shorter than its counterpart
in the test file, so I change `.flexbox > label` to
`display: inline-block` in the reference to fix its height since flex
items are blockified.
Also, remove unused styles.
Differential Revision: https://phabricator.services.mozilla.com/D121827
This commit does three things:
1. It makes thes MSIX test publisher subject "CN=..., OU=...". This
is more like the actual Firefox signing certificates".
2. It moves to use `universal_newlines=True` rather than decoding manually.
3. It fixes an oversight where a particular Powershell invocation
would fail when a certificate was missing.
Differential Revision: https://phabricator.services.mozilla.com/D121902
The issue is that we mark the second input as dirty when it gets the
reflow request (this is as expected), but then during multicol reflow
everything seems to go smoothly, but we hit this code:
https://searchfox.org/mozilla-central/rev/00977c4e37865a92f1c15572ae4aea90e934b25b/layout/generic/nsBlockFrame.cpp#3745
And bail out, leaving the line marked as not dirty, and as such the
stuff inside the page-break-inside: avoid dirty.
When it changes further, we think it's already dirty so don't bother
adding it to the dirty root list anymore and the text frame remains with
its original tiny width.
Differential Revision: https://phabricator.services.mozilla.com/D121869
Installing the Nightly MSIX packages, signed with Mozilla's Nightly
key, yields an error: "Error in parsing the app package." Unpacking
with `makeappx.exe` yields:
```
MakeAppx : error: Error info: error 8007000B: The app manifest publisher name (CN=Mozilla Corporation) must match the subject name of the signing certificate (CN=Mozilla Corporation, OU=Firefox Engineering Operations, O=Mozilla Corporation, L=Mountain View, S=California, C=US).
```
Previously, we allowed just the `CN` to vary; in this patch we make
the publisher be the entire publisher subject, and we update the
publisher details in the task definitions.
Differential Revision: https://phabricator.services.mozilla.com/D121896
After removing `optional` in Bug 1712804, we need to add a variant back
here because there's fallible dependencies. However, I've tweaked the
re-introduction of the feature to require a specific repercussion
message as well. This seemed like a decent tradeoff - the developer
becomes aware that the failure is bad, it has repercussions, but it's
not a blocking issue. Additionally, since we're printing pip's output,
the developer will be able to see the underlying error causing the
warning.
I also added comment functionality to requirements definitions to allow
adjacent documentation of why some requirements are fallible. (Related:
I'm looking forward to `mach_bootstrap` not needing to parse
requirements definitions. Almost there!)
Note that we'll temporarily lose the "pinned" nature of the
three moved dependencies until dependency locking is implemented
for Mach requirements definitions. Also note that the pinned
`zstandard_requirements.txt` can't be removed like the other
files because it still has a dangling usage.
Finally, in preparation for review: I didn't make
`PypiOptionalSpecifier` extend `PypiSpecifier` because I figured that
the benefit of flexibility (easier to allow implementations to diverge
without needing to untangle an inheritance relationship) was larger than
the cost of needing to add properties to both specifiers.
If we wanted re-use, I'd probably have `PypiOptionalSpecifier` _contain_
a `PypiSpecifier`, but then you have to reach deeper into the object to
get data, so *shrug*.
Differential Revision: https://phabricator.services.mozilla.com/D119835
