This comes from bug 890195, and it was superseded by bug 1575097.
This isn't used for anything anymore, and we can remove the otherwise unused
MediaFeatureChangeReason flag as well.
Differential Revision: https://phabricator.services.mozilla.com/D174492
This makes various changes to the named lookup/navigation code to make
them more precise, and avoid issues which could happen if a window is
closed while script is still executing.
This also should improve handling for inactive windows in some cases, by
more frequently working off of the WindowContext tree rather than the
BrowsingContext tree.
As part of these changes, some behaviour was changed around e.g. the
file URI exception to avoid the deprecated nsIPrincipal::GetURI method.
I don't believe the behaviour should have changed in a meaningful way.
Differential Revision: https://phabricator.services.mozilla.com/D171755
This makes various changes to the named lookup/navigation code to make
them more precise, and avoid issues which could happen if a window is
closed while script is still executing.
This also should improve handling for inactive windows in some cases, by
more frequently working off of the WindowContext tree rather than the
BrowsingContext tree.
As part of these changes, some behaviour was changed around e.g. the
file URI exception to avoid the deprecated nsIPrincipal::GetURI method.
I don't believe the behaviour should have changed in a meaningful way.
Differential Revision: https://phabricator.services.mozilla.com/D171755
BrowsingContext::ShouldAddEntryForRefresh expects to be passed the current URI,
to determine if it's the same as the URI for the new load (we shouldn't add a
new entry if they are the same). Before this patch, in the child process we call
BrowsingContext::ShouldAddEntryForRefresh from nsDocShell::MoveLoadingToActiveEntry
(nsDocShell::CreateContentViewer -> Embed -> MoveLoadingToActiveEntry), passing
nsDocShell's mCurrentURI. However, by that point nsDocShell::CreateContentViewer
has already set the mCurrentURI to the newly loading URI (through
nsDocShell::OnNewURI). In the parent process we do pass the correct URI to
BrowsingContext::ShouldAddEntryForRefresh, so the session history ends up being
correct, but depending on timing of the IPC messages there's a brief moment where
index and length are incorrect in the child process (child process and parent
process get a different answer from BrowsingContext::ShouldAddEntryForRefresh).
This causes intermittent failures in the test at
docshell/test/mochitest/test_bug1742865.html.
Differential Revision: https://phabricator.services.mozilla.com/D169544
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
