This should be a better fix. GeckoView assumes these don't change on .top
unless they are explicitly set.
I don't have an Android build environment handy, but I'll try to confirm.
Also, remove an unused flag while at it.
Differential Revision: https://phabricator.services.mozilla.com/D153107
The main goal here is to get the wireframe test to work with
parent-controlled navigation.
This means we don't need to collect the wireframe any more in
PersistLayoutHistoryState, I think, because it is redundant.
I think we need to clear the wireframe in finish restore for
when we navigate back.
As a result of these changes, the two todo subtests in the
wireframe test now pass.
Differential Revision: https://phabricator.services.mozilla.com/D146252
With the use of mStorageAccessPermissionGranted reduced to a single meaning, it turns out to be entirely redundant with the variable on the inner window.
Depends on D147867
Differential Revision: https://phabricator.services.mozilla.com/D147868
With the use of mStorageAccessPermissionGranted reduced to a single meaning, it turns out to be entirely redundant with the variable on the inner window.
Depends on D147867
Differential Revision: https://phabricator.services.mozilla.com/D147868
With the use of mStorageAccessPermissionGranted reduced to a single meaning, it turns out to be entirely redundant with the variable on the inner window.
Depends on D147867
Differential Revision: https://phabricator.services.mozilla.com/D147868
Because wireframes are collected together with the session history
entry for its docshell, we need to collect session history to make
sure that collected wireframes show up.
Differential Revision: https://phabricator.services.mozilla.com/D143368
This property defaults to false. When set to true, user-initiated link clicks in
the top-level BrowsingContext will default target to _blank. This is similar to what
we do for App Tabs, but is slightly more aggressive in that in will also occur for
same-origin navigations.
Differential Revision: https://phabricator.services.mozilla.com/D143374
This property defaults to false. When set to true, user-initiated link clicks in
the top-level BrowsingContext will default target to _blank. This is similar to what
we do for App Tabs, but is slightly more aggressive in that in will also occur for
same-origin navigations.
Differential Revision: https://phabricator.services.mozilla.com/D143374
The previous version had two issues:
It revealed an issue in the old implementation which causes an assertion to fire.
There was also a problem with mDocumentRequest, so the new approach tries to be less clever
and just adds a new boolean member variable mCheckingSessionHistory,
which GetIsAttemptingToNavigate() then uses.
Differential Revision: https://phabricator.services.mozilla.com/D136041
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
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
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
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
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
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
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
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
