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
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
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
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 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
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 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
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
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
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
For consistency with the similar internal DOM API, `As*()` should just cast
the type without checking editor type. Instead, `GetAs*()` should do it.
Differential Revision: https://phabricator.services.mozilla.com/D117381
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
One could optimize out MarkWrapperLive call if stored that wrapper is already live etc, but
in practice that shouldn't matter too much.
Differential Revision: https://phabricator.services.mozilla.com/D117456
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
The change to DoNotifyPossibleTitleChange handling is needed so that we flush the pending title change
before adding a new active entry.
aUpdateEntryInSessionHistory is a bit odd name, since it is really about SHIP only. The patch isn't trying to
fix non-SHIP UI issues, but just give Fission similar behavior what Chrome has.
Differential Revision: https://phabricator.services.mozilla.com/D116504
The crash happens currently when there are more than one loading session history entries at the same time and when
the latter load then accesses current active entry, it has already the bfcached frameloader.
I have tried and failed to write a testcase for this. The Pernosco record is from running
https://searchfox.org/mozilla-central/source/devtools/client/webconsole/test/browser/browser_webconsole_message_categories.js
and the crash has happened when there is a race condition between a load initiated in the parent process and another load initiated in a child
process.
The patch tries to make the setup rather safe. If active entry has changed or it has gotten frameloader, don't try to bfcache.
Differential Revision: https://phabricator.services.mozilla.com/D116410
This allows loads to be tracked as they are ongoing on a per-context basis in
the parent process, and for events to be generated for each subframe as it is
destroyed.
This patch also stops sending the `IsLoadingDocument` flag on the request to
the main process and removes RemoteWebProgress, as they are no longer necessary
due to being tracked directly.
Finally this patch also adds some logging to BrowsingContextWebProgress
to make it easier to diagnose this type of issue in the future.
Differential Revision: https://phabricator.services.mozilla.com/D115706
To restore the stripped query parameters when ETP toggle has been set to
off, we preserve the current unstripped URI to the new loadState when
doing a reload. By doing this, it will redirect the channel back to the
unstripped URI because the loading channel is in the content blocking
allow list and it has a unstripped URI in its loadInfo.
Differential Revision: https://phabricator.services.mozilla.com/D116116
This patch adds an attribute UnstrippedURI in the nsDocShellLoadState.
The attribute will be set if the query stripping was happening.
Otherwise, it will stay a nullptr. This attribute will be propagated to
the loadInfo, so that we can revert the query stripping in the parent
process if the loading URI is in the content blocking allow list. We can
only revert the query stripping in the parent process because we cannot
access the permission of the content blocking allow list of a
cross-origin domain. So, we can only carry the unstripped URI in the
loadInfo and perform a interal redirect to revert the query stripping.
Differential Revision: https://phabricator.services.mozilla.com/D116109
Here's what's going on (relevant browser is browser 36).
[rr 502130 274898]RestoreDocShellState(browser=36, bc=94, )
[rr 502130 274902]RemoteWebNavigation.currentURI browser=36 bc=94 http://mochi.test:8888/#1
[rr 502130 274906]BrowsingContext::LoadURI(browser=36, bc=94, about:blank)
From a previous restore we correctly wait for:
0 _restoreTabContent( <Failed to get argument while inspecting stack frame>
<Failed to get argument while inspecting stack frame>
) ["resource:///modules/sessionstore/SessionStore.jsm":5984:30]
<failed to get 'this' value>
1 _sendRestoreTabContent( <Failed to get argument while inspecting stack frame>
<Failed to get argument while inspecting stack frame>
) ["resource:///modules/sessionstore/SessionStore.jsm":6002:11]
<failed to get 'this' value>
2 restoreTabContent( <Failed to get argument while inspecting stack frame>
<Failed to get argument while inspecting stack frame>
) ["resource:///modules/sessionstore/SessionStore.jsm":4684:9]
<failed to get 'this' value>
3 restoreTab( <Failed to get argument while inspecting stack frame>
<Failed to get argument while inspecting stack frame>
) ["resource:///modules/sessionstore/SessionStore.jsm":4565:13]
<failed to get 'this' value>
4 restoreTabs( <Failed to get argument while inspecting stack frame>
<Failed to get argument while inspecting stack frame>
<Failed to get argument while inspecting stack frame>
aSelectTab = "1") ["resource:///modules/sessionstore/SessionStore.jsm":4413:11]
<failed to get 'this' value>
5 ssi_restoreWindow( <Failed to get argument while inspecting stack frame>
<Failed to get argument while inspecting stack frame>
<Failed to get argument while inspecting stack frame>
) ["resource:///modules/sessionstore/SessionStore.jsm":4189:11]
<failed to get 'this' value>
6 _restoreWindowsFeaturesAndTabs( <Failed to get argument while inspecting stack frame>
) ["resource:///modules/sessionstore/SessionStore.jsm":4275:11]
<failed to get 'this' value>
7 _restoreWindowsInReversedZOrder( <Failed to get argument while inspecting stack frame>
) ["resource:///modules/sessionstore/SessionStore.jsm":4299:9]
<failed to get 'this' value>
8 ssi_restoreWindows/<( <Failed to get argument while inspecting stack frame>
) ["resource:///modules/sessionstore/SessionStore.jsm":4359:11]
[rr 502506 275264]BrowsingContext::LoadURI(browser=36, bc=94, about:blank)
[rr 502506 275268]DocumentChannelChild::AsyncOpen(browser=36, bc=94, about:blank)
[rr 502130 275388]RemoteWebNavigation.currentURI browser=36 bc=94 http://mochi.test:8888/#1
[rr 502506 275629]BrowserChild::OnLocationChange(browser=36, bc=94, about:blank)
[rr 502130 276944]updateForLocationChange browser=36 bc=94 - about:blank
[rr 502130 277084]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank
[rr 502130 277358]RestoreDocShellState(browser=36, bc=94, http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html)
[rr 502506 277378]BrowserChild::OnLocationChange(browser=36, bc=94, http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html)
[rr 502130 277390]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank
[rr 502130 277554]BrowserParent::LoadURL(browser=36, bc=94, about:blank)
From:
#18 0x00007ff0bdb1efcc in mozilla::dom::BrowserParent::LoadURL(nsDocShellLoadState*) (this=0x7ff08f2b9800, aLoadState=0x7ff094e1d580) at /home/emilio/src/moz/gecko/dom/ipc/BrowserParent.cpp:861
#19 0x00007ff0bc1117f9 in nsFrameLoader::ReallyStartLoadingInternal() (this=0x7ff08f283400) at /home/emilio/src/moz/gecko/dom/base/nsFrameLoader.cpp:718
#20 0x00007ff0bc11129f in nsFrameLoader::ReallyStartLoading() (this=0x7ff08f283400) at /home/emilio/src/moz/gecko/dom/base/nsFrameLoader.cpp:640
#21 0x00007ff0bc0002f5 in mozilla::dom::Document::MaybeInitializeFinalizeFrameLoaders() (this=0x7ff0a17e2000) at /home/emilio/src/moz/gecko/dom/base/Document.cpp:9008
#22 0x00007ff0bc057891 in mozilla::detail::RunnableMethodArguments<>::applyImpl<mozilla::dom::Document, void (mozilla::dom::Document::*)()>(mozilla::dom::Document*, void (mozilla::dom::Document::*)(), mozilla::Tuple<>&, std::integer_sequence<unsigned long>) (o=<optimized out>, m=<optimized out>, args=<optimized out>) at /home/emilio/src/moz/gecko/obj-debug/dist/include/nsThreadUtils.h:1150
#23 mozilla::detail::RunnableMethodArguments<>::apply<mozilla::dom::Document, void (mozilla::dom::Document::*)()>(mozilla::dom::Document*, void (mozilla::dom::Document::*)()) (this=<optimized out>, o=<optimized out>, m=<optimized out>)
at /home/emilio/src/moz/gecko/obj-debug/dist/include/nsThreadUtils.h:1156
#24 mozilla::detail::RunnableMethodImpl<mozilla::dom::Document*, void (mozilla::dom::Document::*)(), true, (mozilla::RunnableKind)0>::Run() (this=<optimized out>) at /home/emilio/src/moz/gecko/obj-debug/dist/include/nsThreadUtils.h:1203
#25 0x00007ff0bbef8209 in nsContentUtils::RemoveScriptBlocker() () at /home/emilio/src/moz/gecko/dom/base/nsContentUtils.cpp:5696
#26 0x00007ff0bc11c427 in nsAutoScriptBlocker::~nsAutoScriptBlocker() (this=<optimized out>) at /home/emilio/src/moz/gecko/obj-debug/dist/include/nsContentUtils.h:3499
#27 nsFrameLoaderOwner::ChangeRemotenessCommon(nsFrameLoaderOwner::ChangeRemotenessContextType const&, mozilla::dom::RemotenessChangeOptions const&, bool, bool, mozilla::dom::BrowsingContextGroup*, std::function<void ()>&, mozilla::ErrorResult&) (this=<optimized out>, this@entry=0x7ff0a041b608, aContextType=@0x7ffe238847fc: nsFrameLoaderOwner::ChangeRemotenessContextType::PRESERVE, aOptions=
..., aSwitchingInProgressLoad=false, aIsRemote=<optimized out>, aGroup=<optimized out>, aGroup@entry=0x0, aFrameLoaderInit=..., aRv=...) at /home/emilio/src/moz/gecko/dom/base/nsFrameLoaderOwner.cpp:191
#28 0x00007ff0bc11c81f in nsFrameLoaderOwner::ChangeRemoteness(mozilla::dom::RemotenessOptions const&, mozilla::ErrorResult&) (this=0x7ff0a041b608, aOptions=..., rv=...) at /home/emilio/src/moz/gecko/dom/base/nsFrameLoaderOwner.cpp:250
#29 0x00007ff0bcb59003 in mozilla::dom::XULFrameElement_Binding::changeRemoteness(JSContext*, JS::Handle<JSObject*>, void*, JSJitMethodCallArgs const&)Traceback (most recent call last):
File "/home/emilio/src/moz/gecko/js/src/gdb/mozilla/Root.py", line 55, in to_string
ptr = ptr.dereference()
gdb.error: value has been optimized out
(cx_=<optimized out>, obj=
, void_self=<optimized out>, args=...) at XULFrameElementBinding.cpp:513
#30 0x00007ff0bcecc02a in mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::ThrowExceptions>(JSContext*, unsigned int, JS::Value*) (cx=0x1,
cx@entry=0x7ff0a871b000, argc=<optimized out>, vp=<optimized out>) at /home/emilio/src/moz/gecko/dom/bindings/BindingUtils.cpp:3297
#31 0x00007ff0bf67b1f1 in CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&)
From:
0 updateBrowserRemoteness( <Failed to get argument while inspecting stack frame>
<Failed to get argument while inspecting stack frame>
) ["chrome://browser/content/tabbrowser.js":1937:15]
<failed to get 'this' value>
1 updateBrowserRemotenessByURL( <Failed to get argument while inspecting stack frame>
aURL = ""http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html"") ["chrome://browser/content/tabbrowser.js":2052:20]
<failed to get 'this' value>
2 restoreTabContent( <Failed to get argument while inspecting stack frame>
<Failed to get argument while inspecting stack frame>
) ["resource:///modules/sessionstore/SessionStore.jsm":4662:38]
<failed to get 'this' value>
3 restoreTab( <Failed to get argument while inspecting stack frame>
<Failed to get argument while inspecting stack frame>
) ["resource:///modules/sessionstore/SessionStore.jsm":4565:13]
<failed to get 'this' value>
4 restoreTabs( <Failed to get argument while inspecting stack frame>
<Failed to get argument while inspecting stack frame>
<Failed to get argument while inspecting stack frame>
aSelectTab = "2") ["resource:///modules/sessionstore/SessionStore.jsm":4413:11]
<failed to get 'this' value>
5 ssi_restoreWindow( <Failed to get argument while inspecting stack frame>
<Failed to get argument while inspecting stack frame>
<Failed to get argument while inspecting stack frame>
) ["resource:///modules/sessionstore/SessionStore.jsm":4189:11]
<failed to get 'this' value>
6 _restoreWindowsFeaturesAndTabs( <Failed to get argument while inspecting stack frame>
) ["resource:///modules/sessionstore/SessionStore.jsm":4275:11]
<failed to get 'this' value>
7 _restoreWindowsInReversedZOrder( <Failed to get argument while inspecting stack frame>
) ["resource:///modules/sessionstore/SessionStore.jsm":4299:9]
<failed to get 'this' value>
8 ssi_restoreWindows/<( <Failed to get argument while inspecting stack frame>
) ["resource:///modules/sessionstore/SessionStore.jsm":4359:11]
This load triggers a remoteness change.
[rr 502130 277558]RemoteWebNavigation.currentURI browser=36 bc=94 undefined
[rr 502130 277561]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank
[rr 502130 277564]RestoreDocShellState(browser=36, bc=94, http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html)
[rr 502130 277568]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank
[rr 502130 277572]BrowsingContext::LoadURI(browser=36, bc=94, http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html)
This is the load that should actually end up in the browsing context.
[rr 502578 280053]DocumentChannelChild::AsyncOpen(browser=36, bc=94, about:blank)
From the previous remoteness update.
[rr 502130 280138]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank
[rr 502130 280141]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank
[rr 502130 280143]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank
[rr 502130 280146]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank
At this point, we try to use the BFCache, and end up replacing the
browsing context:
#0 mozilla::dom::CanonicalBrowsingContext::AllowedInBFCache(mozilla::Maybe<unsigned long> const&) (this=0x7ff08f2b5800, aChannelId=...) at /home/emilio/src/moz/gecko/docshell/base/CanonicalBrowsingContext.cpp:2158
#1 0x00007ff0bb3157c1 in mozilla::net::DocumentLoadListener::MaybeTriggerProcessSwitch(bool*) (this=this@entry=0x7ff093b74090, aWillSwitchToRemote=aWillSwitchToRemote@entry=0x7ffe23887838)
at /home/emilio/src/moz/gecko/netwerk/ipc/DocumentLoadListener.cpp:1723
#2 0x00007ff0bb317feb in mozilla::net::DocumentLoadListener::OnStartRequest(nsIRequest*) (this=0x7ff093b74090, aRequest=0x7ff0a0b7a3c8) at /home/emilio/src/moz/gecko/netwerk/ipc/DocumentLoadListener.cpp:2263
#3 0x00007ff0bb238a0c in mozilla::net::ParentChannelListener::OnStartRequest(nsIRequest*) (this=0x7ff08d5c4ee0, aRequest=0x7ff0a0b7a3c8) at /home/emilio/src/moz/gecko/netwerk/protocol/http/ParentChannelListener.cpp:91
#4 0x00007ff0bb9abec2 in nsDocumentOpenInfo::OnStartRequest(nsIRequest*) (this=<optimized out>, request=0x7ff0a0b7a3c8) at /home/emilio/src/moz/gecko/uriloader/base/nsURILoader.cpp:166
#5 0x00007ff0bb32baf0 in mozilla::net::ParentProcessDocumentOpenInfo::OnDocumentStartRequest(nsIRequest*) (this=0x7ff093bc5b80, request=0x7ff0a0b7a3c8) at /home/emilio/src/moz/gecko/netwerk/ipc/DocumentLoadListener.cpp:292
#6 0x00007ff0bae6446c in nsBaseChannel::OnStartRequest(nsIRequest*) (this=<optimized out>, request=<optimized out>) at /home/emilio/src/moz/gecko/netwerk/base/nsBaseChannel.cpp:833
#7 0x00007ff0bae82bdd in nsInputStreamPump::OnStateStart() (this=this@entry=0x7ff08f2593c0) at /home/emilio/src/moz/gecko/netwerk/base/nsInputStreamPump.cpp:481
#8 0x00007ff0bae828d9 in nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) (this=0x7ff08f2593c0, stream=<optimized out>) at /home/emilio/src/moz/gecko/netwerk/base/nsInputStreamPump.cpp:390
#9 0x00007ff0bae8339b in non-virtual thunk to nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) () at /home/emilio/src/moz/gecko/netwerk/base/nsInputStreamPump.cpp:632
#10 0x00007ff0bacd29d5 in mozilla::NonBlockingAsyncInputStream::RunAsyncWaitCallback(mozilla::NonBlockingAsyncInputStream::AsyncWaitRunnable*, already_AddRefed<nsIInputStreamCallback>)
(this=this@entry=0x7ff094eb5a50, aRunnable=aRunnable@entry=0x7ff08f228560, aCallback=...) at /home/emilio/src/moz/gecko/xpcom/io/NonBlockingAsyncInputStream.cpp:397
#11 0x00007ff0bacdf2ec in mozilla::NonBlockingAsyncInputStream::AsyncWaitRunnable::Run() (this=0x7ff08f228560) at /home/emilio/src/moz/gecko/xpcom/io/NonBlockingAsyncInputStream.cpp:33
#12 0x00007ff0bad48d04 in mozilla::RunnableTask::Run() (this=0x7ff093bc5980) at /home/emilio/src/moz/gecko/xpcom/threads/TaskController.cpp:482
#13 0x00007ff0bad316d4 in mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) (this=<optimized out>, this@entry=0x7ff0c54f2400, aProofOfLock=...)
at /home/emilio/src/moz/gecko/xpcom/threads/TaskController.cpp:766
#14 0x00007ff0bad3091d in mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) (this=this@entry=0x7ff0c54f2400, aProofOfLock=...)
at /home/emilio/src/moz/gecko/xpcom/threads/TaskController.cpp:621
#15 0x00007ff0bad30a83 in mozilla::TaskController::ProcessPendingMTTask(bool) (this=0x7ff0c54f2400, aMayWait=false) at /home/emilio/src/moz/gecko/xpcom/threads/TaskController.cpp:405
#16 0x00007ff0bad4388f in mozilla::TaskController::InitializeInternal()::$_0::operator()() const (this=<optimized out>) at /home/emilio/src/moz/gecko/xpcom/threads/TaskController.cpp:138
#17 mozilla::detail::RunnableFunction<mozilla::TaskController::InitializeInternal()::$_0>::Run() (this=<optimized out>) at /home/emilio/src/moz/gecko/obj-debug/dist/include/nsThreadUtils.h:534
#18 0x00007ff0bad3b7f6 in nsThread::ProcessNextEvent(bool, bool*) (this=0x7ff0c541d680, aMayWait=false, aResult=0x7ffe23888437) at /home/emilio/src/moz/gecko/xpcom/threads/nsThread.cpp:1159
#19 0x00007ff0bad3f384 in NS_ProcessNextEvent(nsIThread*, bool) (aThread=0x7ff08f2b5800, aThread@entry=0x7ff0c541d680, aMayWait=false) at /home/emilio/src/moz/gecko/xpcom/threads/nsThreadUtils.cpp:548
#20 0x00007ff0bb43dfe0 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) (this=0x7ff0c54d12c0, aDelegate=0x7ff0c54353e0) at /home/emilio/src/moz/gecko/ipc/glue/MessagePump.cpp:85
#21 0x00007ff0bb3be7b7 in MessageLoop::RunInternal() (this=this@entry=0x7ff0c54353e0) at /home/emilio/src/moz/gecko/ipc/chromium/src/base/message_loop.cc:335
#22 0x00007ff0bb3be707 in MessageLoop::RunHandler() (this=0x7ff0c54353e0) at /home/emilio/src/moz/gecko/ipc/chromium/src/base/message_loop.cc:328
#23 MessageLoop::Run() (this=0x7ff0c54353e0) at /home/emilio/src/moz/gecko/ipc/chromium/src/base/message_loop.cc:310
#24 0x00007ff0bded2bdb in nsBaseAppShell::Run() (this=0x7ff0a880c580) at /home/emilio/src/moz/gecko/widget/nsBaseAppShell.cpp:137
#25 0x00007ff0bf449d85 in nsAppStartup::Run() (this=0x7ff0a883de20) at /home/emilio/src/moz/gecko/toolkit/components/startup/nsAppStartup.cpp:273
#26 0x00007ff0bf5428b6 in XREMain::XRE_mainRun() (this=<optimized out>, this@entry=0x7ffe238887c0) at /home/emilio/src/moz/gecko/toolkit/xre/nsAppRunner.cpp:5239
#27 0x00007ff0bf5433ef in XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) (this=this@entry=0x7ffe238887c0, argc=argc@entry=5, argv=argv@entry=0x7ffe23889a68, aConfig=<optimized out>)
at /home/emilio/src/moz/gecko/toolkit/xre/nsAppRunner.cpp:5437
#28 0x00007ff0bf54385e in XRE_main(int, char**, mozilla::BootstrapConfig const&) (argc=-1816706824, argv=0x7ff0c56441a0, aConfig=...) at /home/emilio/src/moz/gecko/toolkit/xre/nsAppRunner.cpp:5496
#29 0x0000562d08f8e415 in do_main(int, char**, char**) (argc=-1816706824, argv=0x7ffe23889a68, envp=<optimized out>) at /home/emilio/src/moz/gecko/browser/app/nsBrowserApp.cpp:224
[rr 502130 280199]CanonicalBrowsingContext::ReplacedBy(94 -> 104)
[rr 502130 280344]didChangeRemoteness browser=36, bc=104
[rr 502130 280348]RemoteWebNavigation.currentURI browser=36 bc=104 undefined
[rr 502130 280625]RedirectToRealChannel(36, about:blank)
[rr 502578 280695]BrowserChild::OnLocationChange(browser=36, bc=94, http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html)
[rr 502578 280699]BrowsingContext::LoadURI(browser=36, bc=94, http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html)
[rr 502578 280703]DocumentChannelChild::AsyncOpen(browser=36, bc=94, http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html)
This is the LoadURI call for the "final" load, however it went to
the wrong browsing context, as we just replaced this!
[rr 502130 280803]updateForLocationChange browser=36 bc=104 - http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html
[rr 502130 280807]RemoteWebNavigation.currentURI browser=36 bc=104 http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html
[rr 502578 281334]BrowserChild::OnLocationChange(browser=36, bc=104, about:blank)
And this one is from the process switch.
[rr 502130 281461]updateForLocationChange browser=36 bc=104 - about:blank
[rr 502130 281465]RemoteWebNavigation.currentURI browser=36 bc=104 about:blank
[rr 502130 282028]
ⰲ겿{"action":"test_status","time":1621467211822,"thread":null,"pid":null,"source":"mochitest","test":"chrome://mochitests/content/browser/browser/base/content/test/tabs/browser_new_tab_insert_position.js","subtest":"tab pos 0 matched http://mochi.test:8888/#0","status":"PASS","message":"","js_source":"TestRunner.js"}ⰲ겿
[rr 502130 282031]RemoteWebNavigation.currentURI browser=36 bc=104 about:blank
[rr 502130 282033]RemoteWebNavigation.currentURI browser=36 bc=104 about:blank
[rr 502130 282117]
So this is certainly the easy fix, but I think we should generally try
to deal with this better, somehow?
Differential Revision: https://phabricator.services.mozilla.com/D115560
This patch adds a blank page about:third-party along with a skeleton XPCOM
object AboutThirdParty which has a method to invoke a background task in C++.
Differential Revision: https://phabricator.services.mozilla.com/D109303
This patch adds a blank page about:third-party along with a skeleton XPCOM
object AboutThirdParty which has a method to invoke a background task in C++.
Differential Revision: https://phabricator.services.mozilla.com/D109303
This patch adds a blank page about:third-party along with a skeleton XPCOM
object AboutThirdParty which has a method to invoke a background task in C++.
Differential Revision: https://phabricator.services.mozilla.com/D109303
This patch adds a blank page about:third-party along with a skeleton XPCOM
object AboutThirdParty which has a method to invoke a background task in C++.
Differential Revision: https://phabricator.services.mozilla.com/D109303
This should help avoid crashes caused when the content process has
already destroyed a BCG when the parent process hasn't yet. The BCG will
still be destroyed when the content process shuts down using normal
cycle-collection.
Differential Revision: https://phabricator.services.mozilla.com/D113828
Use the newly added session storage data getter to access the session
storage in the parent and store it in session store without a round
trip to content processes.
Depends on D111433
Differential Revision: https://phabricator.services.mozilla.com/D111434
This allows loads to be tracked as they are ongoing on a per-context basis in
the parent process, and for events to be generated for each subframe as it is
destroyed.
This patch also stops sending the `IsLoadingDocument` flag on the request to
the main process and removes RemoteWebProgress, as they are no longer necessary
due to being tracked directly.
Finally this patch also adds some logging to BrowsingContextWebProgress
to make it easier to diagnose this type of issue in the future.
Differential Revision: https://phabricator.services.mozilla.com/D115706
This allows loads to be tracked as they are ongoing on a per-context basis in
the parent process, and for events to be generated for each subframe as it is
destroyed.
This patch also stops sending the `IsLoadingDocument` flag on the request to
the main process and removes RemoteWebProgress, as they are no longer necessary
due to being tracked directly.
Finally this patch also adds some logging to BrowsingContextWebProgress
to make it easier to diagnose this type of issue in the future.
Differential Revision: https://phabricator.services.mozilla.com/D115706
Use the newly added session storage data getter to access the session
storage in the parent and store it in session store without a round
trip to content processes.
Depends on D111433
Differential Revision: https://phabricator.services.mozilla.com/D111434
We strip the target query parameters in BrowsingContext::LoadURI(). This
is needed for the loading from the RemoteWebNavigation. The parent
process will create the channel before the loading happens in the
nsDocShell in content process. So we have to strip before the channel
has been created in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D113844
The target query parameters will be stripped from the loading URI in
nsDocShell before creating the channel for the loading. We will only
strip the URI for top-level loading but not for frames. It's because
there is no need to strip frames if we've stripped in top-level already.
Differential Revision: https://phabricator.services.mozilla.com/D113843
This should help avoid crashes caused when the content process has
already destroyed a BCG when the parent process hasn't yet. The BCG will
still be destroyed when the content process shuts down using normal
cycle-collection.
Differential Revision: https://phabricator.services.mozilla.com/D113828
Running AssertDocGroupMatchesKey() on an unlinked document can cause
a crash in debug builds, so pass in the group directly, because all
of the callers are Documents so they already have it.
Differential Revision: https://phabricator.services.mozilla.com/D115272
With Fission, there can be multiple BrowserParents in a single tab, so
this patch moves the tracking of active tabs onto the top BrowsingContext
in a tab. If the priority of a top BC is changed, then the activity
of all of the BPs of the BCs in the tree are all adjusted. The flag
that tracks this state gets carried forward to the new BC in the case
of a cross-group navigation by the changes in ReplacedBy().
The other change here covers the case where we do a process-switching
navigation on an iframe. If we create a new BrowserParent with an active
top BC, then the BP gets marked as active in the priority manager. Doing
this tracking on the BP instead of the BC (both here in and in the part
that landed previously in BrowserParent::Deactivated()) means that we
don't need to track down every place that a BC switches processes.
I left the tracking of activity in ParticularProcessPriorityManager
centered around BrowserParents, instead of changing it to BCs, to
minimize the changes required. There are some tricky interactions there
with wakelocks that I didn't want to have to figure out.
browser_ProcessPriorityManager.js was set up to track a mapping of
browsers to priorities, but for the purposes of testing Fission support
I changed it to track a mapping of child IDs to priorities.
In the test, I also removed an assignment (this.window = null) that
didn't seem to be doing anything.
Differential Revision: https://phabricator.services.mozilla.com/D112213
This should help avoid crashes caused when the content process has
already destroyed a BCG when the parent process hasn't yet. The BCG will
still be destroyed when the content process shuts down using normal
cycle-collection.
Differential Revision: https://phabricator.services.mozilla.com/D113828
With Fission, there can be multiple BrowserParents in a single tab, so
this patch moves the tracking of active tabs onto the top BrowsingContext
in a tab. If the priority of a top BC is changed, then the activity
of all of the BPs of the BCs in the tree are all adjusted. The flag
that tracks this state gets carried forward to the new BC in the case
of a cross-group navigation by the changes in ReplacedBy().
The other change here covers the case where we do a process-switching
navigation on an iframe. If we create a new BrowserParent with an active
top BC, then the BP gets marked as active in the priority manager. Doing
this tracking on the BP instead of the BC (both here in and in the part
that landed previously in BrowserParent::Deactivated()) means that we
don't need to track down every place that a BC switches processes.
I left the tracking of activity in ParticularProcessPriorityManager
centered around BrowserParents, instead of changing it to BCs, to
minimize the changes required. There are some tricky interactions there
with wakelocks that I didn't want to have to figure out.
browser_ProcessPriorityManager.js was set up to track a mapping of
browsers to priorities, but for the purposes of testing Fission support
I changed it to track a mapping of child IDs to priorities.
In the test, I also removed an assignment (this.window = null) that
didn't seem to be doing anything.
Differential Revision: https://phabricator.services.mozilla.com/D112213
This should help avoid message ordering issues in the next patches. To ensure
that we're not firing events too early, we now do a "full" restore even if we
don't have form or scroll data, including for about:blank URIs.
This also moves all restore state on the CanonicalBrowsingContext into a
separate `mRestoreState` struct.
Differential Revision: https://phabricator.services.mozilla.com/D110333
This also fixes test
browser/base/content/test/tabs/browser_navigate_through_urls_origin_attributes.js
which was failing for fission + bfcacheInParent, because about:privatebrowsing
was getting bfcached, and an extra XULFrameLoaderCreated event was firing, when
we were not expecting it.
Differential Revision: https://phabricator.services.mozilla.com/D112441
This should help avoid message ordering issues in the next patches. To ensure
that we're not firing events too early, we now do a "full" restore even if we
don't have form or scroll data, including for about:blank URIs.
This also moves all restore state on the CanonicalBrowsingContext into a
separate `mRestoreState` struct.
Differential Revision: https://phabricator.services.mozilla.com/D110333
This removes some sketchy non-caching of cursors on windows while at it,
now that plugins are gone, but otherwise shouldn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D112475
This makes it trivial to choose the right BrowserParent to print a
browsing context, by removing the OuterWindowID / FrameLoader
indirections.
Differential Revision: https://phabricator.services.mozilla.com/D112412
Also, make sure we update layout history state from docshell before we load a
new URI, as it might be our last chance to do so before a process swap.
Differential Revision: https://phabricator.services.mozilla.com/D110994
Just like how for window.open() it's checked on the opener, of course.
Note that when sending the focus request via IPC, we trust the check
done on the child (bug 1677899).
Do we have a good test to extend to cover this case?
Differential Revision: https://phabricator.services.mozilla.com/D111107
Cristian Tuns
Tim Huang
Noemi Erli
Emilio Cobos Álvarez
Karl Tomlinson
Johann Hofmann
Nika Layzell
Peter Van der Beken
Edgar Chen
Alexandru Michis
Olli Pettay
Iulian Moraru
criss
Butkovits Atila
owlishDeveloper
Sandor Molnar
Valentin Gosu
Benjamin Peterson
Florian Quèze
Timothy Nikkel
Daisuke Akatsuka
Andi-Bogdan Postelnicu
André Bargull
Mike Conley
Cosmin Sabou
Sebastian Hengst
Henri Sivonen
Anny Gakhokidze
Kashav Madan
alwu
Dorel Luca
Ted Campbell
Hiroyuki Ikezoe
Kris Maglione
Manuel Bucher
Alexandre Poirot
Gijs Kruitbosch
Andreas Farre
Marian-Vasile Laza
Masayuki Nakano
Hubert Boma Manilla
Yaron Tausky
Dana Keeler
Brindusan Cristian
Toshihito Kikuchi
Csoregi Natalia
Niklas Goegge
Andreea Pavel
Andrew McCreight
Narcis Beleuzu
Christoph Kerschbaumer
lyavor