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
Nika Layzell
Peter Van der Beken
Edgar Chen
Alexandru Michis
Olli Pettay
Iulian Moraru
criss
Butkovits Atila
owlishDeveloper
Noemi Erli
Sandor Molnar
Valentin Gosu
Michelle Goossens
Benjamin Peterson
Marian-Vasile Laza
Florian Quèze
Mike Conley
Timothy Nikkel
Henri Sivonen
Mark Banner