Document::GetBrowsingContext uses a WeakPtr<nsIDocShell> so we can't do
that. But we have all the other media emulation data and so on in the
pres context which we can access off the main thread for style, so move the
override code there.
Differential Revision: https://phabricator.services.mozilla.com/D128673
Currently, we are using the regular principal and inherited regular
principal to create clientSource in nsDocShell. This patch makes the
nsDocshell to use the partitioned principal if needed.
Differential Revision: https://phabricator.services.mozilla.com/D127629
Currently, we are using the regular principal and inherited regular
principal to create clientSource in nsDocShell. This patch makes the
nsDocshell to use the partitioned principal if needed.
Differential Revision: https://phabricator.services.mozilla.com/D127629
Currently, we are using the regular principal and inherited regular
principal to create clientSource in nsDocShell. This patch makes the
nsDocshell to use the partitioned principal if needed.
Differential Revision: https://phabricator.services.mozilla.com/D127629
Currently, we are using the regular principal and inherited regular
principal to create clientSource in nsDocShell. This patch makes the
nsDocshell to use the partitioned principal if needed.
Differential Revision: https://phabricator.services.mozilla.com/D127629
Currently, we are using the regular principal and inherited regular
principal to create clientSource in nsDocShell. This patch makes the
nsDocshell to use the partitioned principal if needed.
Differential Revision: https://phabricator.services.mozilla.com/D127629
The issue is that when going back from a non-bfcacheable page to a bfcacheable page and the first page
modifies requested index around the same time, UpdateIndex() doesn't have the right requested index. This is a variant of bug 1725680.
The test case loads a non-bfcacheable page, then bfcachable, then another non-bfcacheable and then goes back and forward.
Without the patch indexes go wrong and forward doesn't do anything.
Differential Revision: https://phabricator.services.mozilla.com/D127963
We make it work on macOS by setting pointer-events: none + opacity: 0 rather
than visibility: hidden, and tweaking the caching setup to be Android-like.
Now that the scrollbars sheet is the same across platforms, move it to where
the rest of the UA sheets are. This way we guarantee that the RDM vs. Android
difference is less (just the ifdef at the top of the sheet).
Depends on D128084
Differential Revision: https://phabricator.services.mozilla.com/D128085
This is a pretty cheap way of fixing this bug by saying nsDocShell::loadURI calls
done with a system principal will add user interaction to the current page. This takes
advantage of the fact that all UI code for loading URIs goes through this code path.
Note that during debugging I've found other cases where SH entries would be added with
a system principal, most notably when navigating to URL hashes/fragments (example.com#hash).
I'm not sure why this is happening but it doesn't go through nsDocShell::loadURI.
Differential Revision: https://phabricator.services.mozilla.com/D127558
When we navigate in history to the same entry that we're current at then we
actually do a reload. The problem is in the way we detect whether to do a reload
in the parent process.
If a page does a back and a forward one after the other in a script, then the
parent will calculate the index for the back and tell the child to load the
entry at that index. While the child is processing the load of that entry, the
BC in the parent process still has the same entry as its active entry (until the
child commits the load of the entry over IPC). The parent then processes the
forward, calculates the index for the forward and finds the entry at that index.
This is the same entry that we were at before doing anything, and so the same
entry as the active entry in the BC in the parent process. We used to compare
the entry that we're going to load with the active entry in the BC to determine
whether we're doing a reload, and so in this situation we would assume the
forward navigation was actually doing a reload. The child would reload the page,
and we'd run the script again and we'd end up in a reload loop.
Comparing the offset with 0 to determine whether we're doing a reload fixes this
issue.
Differential Revision: https://phabricator.services.mozilla.com/D126585
This is a intermediate solution to make popup block could work with new user
activation model (timer base). I think this should cover most of async case for
`window.open()`. For long term, we still need to clean up the popup state which
is tracked by bug 1656444.
Differential Revision: https://phabricator.services.mozilla.com/D126879
When we navigate in history to the same entry that we're current at then we
actually do a reload. The problem is in the way we detect whether to do a reload
in the parent process.
If a page does a back and a forward one after the other in a script, then the
parent will calculate the index for the back and tell the child to load the
entry at that index. While the child is processing the load of that entry, the
BC in the parent process still has the same entry as its active entry (until the
child commits the load of the entry over IPC). The parent then processes the
forward, calculates the index for the forward and finds the entry at that index.
This is the same entry that we were at before doing anything, and so the same
entry as the active entry in the BC in the parent process. We used to compare
the entry that we're going to load with the active entry in the BC to determine
whether we're doing a reload, and so in this situation we would assume the
forward navigation was actually doing a reload. The child would reload the page,
and we'd run the script again and we'd end up in a reload loop.
Comparing the offset with 0 to determine whether we're doing a reload fixes this
issue.
Differential Revision: https://phabricator.services.mozilla.com/D126585
This is a much simplified patch compared to the earlier changes, and
aims to be less risky and avoid whatever issues are being caused by the
process selection changes in the earlier patches. Unfortunately, I think
this patch may reduce the ability for a noopener window to be given a
distinct process, so I would prefer a more complete fix in the future.
This new patch also no longer has a fix for bug 1728331, so that will
need to be fixed separately.
Differential Revision: https://phabricator.services.mozilla.com/D126951
Using requestedIndex on the child side is hard, because there are race conditions when a session history load is triggered
and at the same time a non-session history load commits a new active entry.
Differential Revision: https://phabricator.services.mozilla.com/D126619
When we navigate in history to the same entry that we're current at then we
actually do a reload. The problem is in the way we detect whether to do a reload
in the parent process.
If a page does a back and a forward one after the other in a script, then the
parent will calculate the index for the back and tell the child to load the
entry at that index. While the child is processing the load of that entry, the
BC in the parent process still has the same entry as its active entry (until the
child commits the load of the entry over IPC). The parent then processes the
forward, calculates the index for the forward and finds the entry at that index.
This is the same entry that we were at before doing anything, and so the same
entry as the active entry in the BC in the parent process. We used to compare
the entry that we're going to load with the active entry in the BC to determine
whether we're doing a reload, and so in this situation we would assume the
forward navigation was actually doing a reload. The child would reload the page,
and we'd run the script again and we'd end up in a reload loop.
Comparing the offset with 0 to determine whether we're doing a reload fixes this
issue.
Differential Revision: https://phabricator.services.mozilla.com/D126585
This patch replaces the previous process selection infrastructure with a
new setup implemented entirely in C++, which should more accurately
track the set of processes in use, and should encourage re-use of the
existing content process when navigating by not counting the current
tab.
This approach intentionally allows for process switching to another
process during navigation if there is uneven load between processes to
encourage balanced process use.
I think this may also fix some of the session restore issues with many
tabs using the same process, rather than being spread over 4, as we now
track a tab earlier in its lifecycle before the BrowserParent instance
is created.
Differential Revision: https://phabricator.services.mozilla.com/D126405
This patch replaces the previous process selection infrastructure with a
new setup implemented entirely in C++, which should more accurately
track the set of processes in use, and should encourage re-use of the
existing content process when navigating by not counting the current
tab.
This approach intentionally allows for process switching to another
process during navigation if there is uneven load between processes to
encourage balanced process use.
I think this may also fix some of the session restore issues with many
tabs using the same process, rather than being spread over 4, as we now
track a tab earlier in its lifecycle before the BrowserParent instance
is created.
Differential Revision: https://phabricator.services.mozilla.com/D126405
This version doesn't change SetContainer handling, since it seems to be tricky for the top level page.
So only activity change notification is fired and IsActive() is updated.
The comment about IsActive() was wrong even with the old bfcache implementation.
(I did check that it returned false when the page was in bfcache and many of the activity observers rely on that)
The changes to HTMLMediaElement are needed to ensure page can enter bfcache..
Differential Revision: https://phabricator.services.mozilla.com/D124684
The biggest change in this patch is around the PrepareToChangeRemoteness
promise. It is changed to directly interact with the DOM promise rather than
wrapping it into a MozPromise (which requires another trip through the event
loop), and tries to avoid waiting on the promise at all if it was immediately
resolved (which should always be the case with SHIP enabled, except for in a
single test).
Differential Revision: https://phabricator.services.mozilla.com/D124800
The biggest change in this patch is around the PrepareToChangeRemoteness
promise. It is changed to directly interact with the DOM promise rather than
wrapping it into a MozPromise (which requires another trip through the event
loop), and tries to avoid waiting on the promise at all if it was immediately
resolved (which should always be the case with SHIP enabled, except for in a
single test).
Differential Revision: https://phabricator.services.mozilla.com/D124800
SetContainer handling is similar to what DocumentViewer does for the old bfcache implementation.
(The old implementation hides it quite well).
The changes to HTMLMediaElement are needed to ensure page can enter bfcache.
Removed erroneous MOZ_ASSERT in nsPresContext, it is ok to trigger that code path in the new implementation.
And the Run() method of the relevant nsIRunnable already deals with that case.
Differential Revision: https://phabricator.services.mozilla.com/D124684
Getting all the requests from the loadgroup every time a request
is added or removed was causing performance issues. It turns out
that it wasn't really needed for determining if a page should be
blocked from the BFCache, since we just need to know if there
are any requests in the loadgroup, and if so, if all it contains
is just one request with an id. We can keep a count of relevant
requests in the loadgroup. When the count changes to 1, on adding
we can inspect the request that's being added, and on removal we
can inspect the requests in the loadgroup (which should be now be
cheap enough, since there's only 1 relevant request in the list).
Differential Revision: https://phabricator.services.mozilla.com/D125251
The biggest change in this patch is around the PrepareToChangeRemoteness
promise. It is changed to directly interact with the DOM promise rather than
wrapping it into a MozPromise (which requires another trip through the event
loop), and tries to avoid waiting on the promise at all if it was immediately
resolved (which should always be the case with SHIP enabled, except for in a
single test).
Differential Revision: https://phabricator.services.mozilla.com/D124800
I am not confident that this will fix the underlying issue causing this crash,
but given how small of a change it is, I figure it's worth trying to land
quickly to see if the crash rate drops with it.
Differential Revision: https://phabricator.services.mozilla.com/D124503
This field will be useful to JS code such as JSWindowActors which need to be
able to detect when their WindowContext is no longer active.
Differential Revision: https://phabricator.services.mozilla.com/D124098
This makes the method's name more consistent with IsContentSubframe, and is
probably more clear than IsFrame (as a <browser> could be considered a frame).
Depends on D124211
Differential Revision: https://phabricator.services.mozilla.com/D124212
This method actually tracks whether the context is current, so it has been
renamed, and the behaviour has been inverted.
Depends on D124210
Differential Revision: https://phabricator.services.mozilla.com/D124211
These codepaths will never be taken with SHIP enabled, and this patch adds a
couple assertions to keep track of that information for when we rip out SHIP.
Differential Revision: https://phabricator.services.mozilla.com/D124210
The fix let's ContentParent::RecvSynchronizeLayoutHistoryState update the layout history state.
Using an existing test to launch a subtest for this. Hopefully the description of the test helps with reviewing it.
(These BroadcastChannel based tests can be hard to follow.)
Differential Revision: https://phabricator.services.mozilla.com/D122376
NOTE! In cases where there is no HTTP-layer encoding declaration, and CSS
parsing inherits the encoding from the HTML document, for preloads, this
changes the inherited encoding from windows-1252 to UTF-8 in order to
make the speculative encoding correct in the common `<meta charset=utf-8>`
case.
Differential Revision: https://phabricator.services.mozilla.com/D123593
After some investigation, I was able to find a theoretical codepath
which could lead to the "missing initial frame browsing context" error:
1. Two iframes are created for the same origin, and begin process
switching.
2. The first iframe finishes process switching, but for some reason
(e.g. being in shutdown) the call to `LaunchSubprocessResolve`
errors.
3. The second callback is called and also calls LaunchSubprocessResolve,
which this time returns `true` due to it previously having been
called.
4. The BrowserParent is created in the new content process despite
`InitInternal()` never having been finished, and therefore the
ContentParent never becoming subscribed to the BrowsingContextGroup.
To fix this, I made 2 changes:
1. Abort from process switching if the target process which we're going
to be creating a BrowserParent in `IsDead()`, and
2. Track the return value from `LaunchSubprocessResolve`, so we return
`false` if it is called a second time after a failed content process
launch.
I'm not confident that this is the cause of the crashes, as I was unable
to reproduce the issue.
Differential Revision: https://phabricator.services.mozilla.com/D123548
This will, for example, make it possible to behave differently for a normal navigation,
a reload navigation, a history navigation, and a pushstate navigation.
Differential Revision: https://phabricator.services.mozilla.com/D122532
Looks like the code below does similar thing already for iframes, so this is adding InternalSetRequestedIndex
call only for the top level case.
This is based on the same assumptions as bug 1697905, but unfortunately testing this is still
super hard.
Differential Revision: https://phabricator.services.mozilla.com/D122355
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
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
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
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
To support more cases, change this value to more general name and use a count instead, if the count is larger than zero, then we would not suspend the page.
In addition, this value now can be set in any processes (but still for the top level only), which is different from before where we would only set the value from the chrome process.
Differential Revision: https://phabricator.services.mozilla.com/D119837
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
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
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
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
This accomplishes 2 things:
1. Allows us to directly fetch the layersId of the process that is
autoscrolling, which avoids having to fetch it in AutoScrollChild and pass it
around. This fixes autoscrolling out-of-process frames with Fission enabled.
2. Makes it easier to handle autoscrolling of in-process documents, since that
can't happen through PBrowser.
Differential Revision: https://phabricator.services.mozilla.com/D120766
This accomplishes 2 things:
1. Allows us to directly fetch the layersId of the process that is
autoscrolling, which avoids having to fetch it in AutoScrollChild and pass it
around. This fixes autoscrolling out-of-process frames with Fission enabled.
2. Makes it easier to handle autoscrolling of in-process documents, since that
can't happen through PBrowser.
Differential Revision: https://phabricator.services.mozilla.com/D120766
Instead of initializing on first use - which can race with workers - do the
initialization in nsLayoutStatics::Initialize(). Also make `sInShutdown` an
Atomic since it is accessed without locks.
Differential Revision: https://phabricator.services.mozilla.com/D121143
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
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
There are a number of modules that we import from C++ and can't continue
running without. We have a number of crashes for some of those failed loads. A
lot of them are from OOMs or corruption, but we're not sure about the rest.
This patch adds a crash annotation with the details of the error wherever we
abort for failing to load a module.
Differential Revision: https://phabricator.services.mozilla.com/D120290
There are a number of modules that we import from C++ and can't continue
running without. We have a number of crashes for some of those failed loads. A
lot of them are from OOMs or corruption, but we're not sure about the rest.
This patch adds a crash annotation with the details of the error wherever we
abort for failing to load a module.
Differential Revision: https://phabricator.services.mozilla.com/D120290
Ensure firing the onStateChange on the BrowsingContext's WebProgress
of the page we navigate *from* instead of the one we navigate *to*.
(which was what used to happen before fission/bfcacheInParent)
Differential Revision: https://phabricator.services.mozilla.com/D119648
I don't have a test for this, since the race condition is super hard to trigger.
The patch is based on code auditing.
The patch just prevents bfcaching if we're in middle of another load.
Differential Revision: https://phabricator.services.mozilla.com/D119992
This makes sure to clear and set the value more consistently when replacing
documents within a WindowGlobal, and makes sure to include the relevant flag in
the initializer.
In addition, the place where the flag is set is moved ahead to happen before
the call to `Embed` so that the information is ready before the window is
created.
Differential Revision: https://phabricator.services.mozilla.com/D119815
This moves the logic of whether a pres shell should be active to a
single place to make it sane to reason about, and fixes the
subdocument propagation when a BrowserChild becomes visible.
Differential Revision: https://phabricator.services.mozilla.com/D118703
Move the counting of private browsing contexts to the parent
process. Also change to only consider non-chrome browsing contexts
when counting private contexts. The latter is possible due to bug
1528115, because we no longer need to support hidden private windows.
With counting in the parent process we can make sure that when we're
changing remoteness on a private browsing context the private browsing
context count never drops to zero. This fixes an issue with Fission,
where we remoteness changes could transiently have a zero private
browsing context count, that would be mistaken for the last private
browsing context going away.
Changing to only count non-chrome browsing contexts makes us only fire
'last-pb-context-exited' once, and since we count them in the parent
there is no missing information about contexts that makes us wait for
a content process about telling us about insertion or removal of
browsing contexts.
Differential Revision: https://phabricator.services.mozilla.com/D118182
Move the counting of private browsing contexts to the parent
process. Also change to only consider non-chrome browsing contexts
when counting private contexts. The latter is possible due to bug
1528115, because we no longer need to support hidden private windows.
With counting in the parent process we can make sure that when we're
changing remoteness on a private browsing context the private browsing
context count never drops to zero. This fixes an issue with Fission,
where we remoteness changes could transiently have a zero private
browsing context count, that would be mistaken for the last private
browsing context going away.
Changing to only count non-chrome browsing contexts makes us only fire
'last-pb-context-exited' once, and since we count them in the parent
there is no missing information about contexts that makes us wait for
a content process about telling us about insertion or removal of
browsing contexts.
Differential Revision: https://phabricator.services.mozilla.com/D118182
Move the counting of private browsing contexts to the parent
process. Also change to only consider non-chrome browsing contexts
when counting private contexts. The latter is possible due to bug
1528115, because we no longer need to support hidden private windows.
With counting in the parent process we can make sure that when we're
changing remoteness on a private browsing context the private browsing
context count never drops to zero. This fixes an issue with Fission,
where we remoteness changes could transiently have a zero private
browsing context count, that would be mistaken for the last private
browsing context going away.
Changing to only count non-chrome browsing contexts makes us only fire
'last-pb-context-exited' once, and since we count them in the parent
there is no missing information about contexts that makes us wait for
a content process about telling us about insertion or removal of
browsing contexts.
Differential Revision: https://phabricator.services.mozilla.com/D118182
During a `TextControlState` alive, `PasswordMaskData` should be alive too.
Otherwise, we cannot keep unmasked range at reframing.
Depends on D118756
Differential Revision: https://phabricator.services.mozilla.com/D118757
We can't rely on the Children list since it may have been cleared on shutdown.
Since we don't clear parent edges, walking the parent chain and using
mChildOffset works.
Differential Revision: https://phabricator.services.mozilla.com/D118384
We can't rely on the Children list since it may have been cleared on shutdown.
Since we don't clear parent edges, walking the parent chain and using
mChildOffset works.
Differential Revision: https://phabricator.services.mozilla.com/D118384
This moves the logic of whether a pres shell should be active to a
single place to make it sane to reason about, and fixes the
subdocument propagation when a BrowserChild becomes visible.
Differential Revision: https://phabricator.services.mozilla.com/D118703
We can't rely on the Children list since it may have been cleared on shutdown.
Since we don't clear parent edges, walking the parent chain and using
mChildOffset works.
Differential Revision: https://phabricator.services.mozilla.com/D118384
If a <browser> is removed in the middle of a process change, the previous
DocShell may be torn down while it's still expecting a process change. There's
really nothing more to do in that case, though, so we can just skip the
PrepareForProcessChange call rather than asserting.
Differential Revision: https://phabricator.services.mozilla.com/D118514
If we're destroying the frame loader of a replaced browsing context we'll end up
firing browser-shutdown-tabstate-updated for a tab that wasn't actually closed.
This results in us cleaning up Session Store state earlier than expected, which
means we drop future updates to SessionStoreInternal._closedTabs.
Fixes browser_sessionHistory.js, browser_async_remove_tab.js, and possibly
browser_491168.js for SHIP+BFCache.
Differential Revision: https://phabricator.services.mozilla.com/D117944
The previous version was trying to make index handling too generic.
But history loads need to update index to the requested index, not to the index of the current entry,
because the requested index was already passed to the child process when the
history load started. If there are several pending history loads, commit of the first one
will update the index based on requested index and send new index to the child.
When child side receives the index update, other pending history loads have been already
processed.
New loads can just clear the requested index, since the child side has
PendingSHistoryChange object to update the effective index and length to the
correct one and when parent side sends back the current index and length the
relevant PendingSHistoryChange object is removed.
With this version both
testing/web-platform/tests/old-tests/submission/Microsoft/history/history_000.htm
and
docshell/test/navigation/browser_test_simultaneous_normal_and_history_loads.js
pass now even on a debug build.
I think there might be a case for the issue happening also without SHIP, but
since it is way less asynchronous, triggering that issue is hard.
So the patch and test are for SHIP only.
Differential Revision: https://phabricator.services.mozilla.com/D116744
Not setting mIsSrcdocEntry causes us to drop srcdoc data and not set
INTERNAL_LOAD_FLAGS_IS_SRCDOC in FillLoadInfo for srcdoc restores.
Differential Revision: https://phabricator.services.mozilla.com/D117479
This is slightly complicated by the fact that the editor code wants to be able
to set this from the content process, so we really need separate
BrowsingContext and WindowContext flags, the latter of which can be set by the
owning process.
Differential Revision: https://phabricator.services.mozilla.com/D114899
The public key pinning implementation is much less complex than the HSTS
implementation, and only needs a small subset of the parameters of the latter.
Furthermore, the information it relies on is static, and so is safe to access
from content processes. This patch separates the two implementations, thus
simplifying both of them and avoiding some unnecessary IPC calls in the
process.
Differential Revision: https://phabricator.services.mozilla.com/D117096
The public key pinning implementation is much less complex than the HSTS
implementation, and only needs a small subset of the parameters of the latter.
Furthermore, the information it relies on is static, and so is safe to access
from content processes. This patch separates the two implementations, thus
simplifying both of them and avoiding some unnecessary IPC calls in the
process.
Differential Revision: https://phabricator.services.mozilla.com/D117096
Evgenia Kotovich
Butkovits Atila
Emilio Cobos Álvarez
Tim Huang
Gerald Squelart
Cosmin Sabou
Sean Feng
Paul Zuehlcke
criss
Noemi Erli
Andreea Pavel
Cristian Tuns
Alexandru Michis
Christoph Kerschbaumer
Olli Pettay
Karl Tomlinson
Johann Hofmann
Tomislav Jovanovic
Nika Layzell
Peter Van der Beken
Edgar Chen
Iulian Moraru
owlishDeveloper
Sandor Molnar
Valentin Gosu
Michelle Goossens
Benjamin Peterson
Marian-Vasile Laza
Florian Quèze
Mike Conley
Timothy Nikkel
Henri Sivonen
Mark Banner
Daisuke Akatsuka
Andi-Bogdan Postelnicu
André Bargull
Sebastian Hengst
Geoff Brown
Anny Gakhokidze
Kashav Madan
alwu
Dorel Luca
Ted Campbell
Hiroyuki Ikezoe
Kris Maglione
Manuel Bucher
Csoregi Natalia
Alexandre Poirot
Geoff Lankow
Matt Woodrow
Gijs Kruitbosch
Andreas Farre
Masayuki Nakano
Hubert Boma Manilla
Andrew Halberstadt
Yaron Tausky
Dana Keeler