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
If one closes the last tab with the session restore enabled, it will re-open after restart.
Fix that by closing completely the tabs before the stop of the browser.
Differential Revision: https://phabricator.services.mozilla.com/D118270
If one closes the last tab with the session restore enabled, it will re-open after restart.
Fix that by closing completely the tabs before the stop of the browser.
Differential Revision: https://phabricator.services.mozilla.com/D118270
This causes us to handle middle clicks twice for menuitems, which results in us
opening two recent tabs instead of one. The regressing bug dealt with similar
problems in D112046.
This also updates the other RecentlyClosedTabsAndWindowsMenuUtils.get*Fragment
caller to use the full function names instead of strings.
Differential Revision: https://phabricator.services.mozilla.com/D119544
When we duplicate a tab, we don't need to have about:blank load in it, because
we are going to use restore mechanism to copy data into the new tab. If we
don't skip the superfluous load, the restoring process might race with the
loading of about:blank, and sometimes we might try to destroy the
WindowGlobalChild actor just as SessionStore is trying to restore docshell
capabilities for that tab resulting in a rejected promise in _restoreHistory
and `_restoreHistoryComplete` not getting called.
Differential Revision: https://phabricator.services.mozilla.com/D119313
When we duplicate a tab, we don't need to have about:blank load in it, because
we are going to use restore mechanism to copy data into the new tab. If we
don't skip the superfluous load, the restoring process might race with the
loading of about:blank, and sometimes we might try to destroy the
WindowGlobalChild actor just as SessionStore is trying to restore docshell
capabilities for that tab resulting in a rejected promise in _restoreHistory
and `_restoreHistoryComplete` not getting called.
Differential Revision: https://phabricator.services.mozilla.com/D119313
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
Not setting mIsSrcdocEntry causes us to drop srcdoc data and not set
INTERNAL_LOAD_FLAGS_IS_SRCDOC in FillLoadInfo for srcdoc restores.
Differential Revision: https://phabricator.services.mozilla.com/D117479
This is slightly complicated by the fact that the editor code wants to be able
to set this from the content process, so we really need separate
BrowsingContext and WindowContext flags, the latter of which can be set by the
owning process.
Differential Revision: https://phabricator.services.mozilla.com/D114899
This does a few things:
1. Removes the `aImmediately` flag from the RequestSHistoryUpdate path, and
moves that responsibility to SessionStore
1. Simplifies how and when SessionStore calls SessionHistory.collectFromParent()
1. Attempts to clean-up SessionStore's SHistoryListener (again)
Differential Revision: https://phabricator.services.mozilla.com/D117230
Session Storage used to share implementation with Local Storage, where
a distinction of a default data set from a session data set made
sense. In Session Storage all data is actually scoped by the
session. Since Bug 1322316 Session Storage no longer share
implementation with Local Storage, which makes it safe to collapse the
datasets in Session Storage to one dataset, which makes life easier,
especially for Session (Re-)Store.
Differential Revision: https://phabricator.services.mozilla.com/D116609
