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
Replaces the `isFinal` bit with a "browser-shutdown-tabstate-updated" observer
notification, which is fired after all frames in the document are flushed.
Differential Revision: https://phabricator.services.mozilla.com/D116146
Using autofocus="true" or programmatically calling .focus() when there is no pre-existing focused
element causes the :focus-visible to match.
This patch avoids using autofocus="true" on some of our about: pages, and uses
Element.focus({ preventFocusRing: true }) to avoid that when these pages and dialog
first load. Note that this doesn't prevent the focus ring from _ever_ appear, it just
stops it from appearing on first load.
Differential Revision: https://phabricator.services.mozilla.com/D115062
Using autofocus="true" or programmatically calling .focus() when there is no pre-existing focused
element causes the :focus-visible to match.
This patch avoids using autofocus="true" on some of our about: pages, and uses
Element.focus({ preventFocusRing: true }) to avoid that when these pages and dialog
first load. Note that this doesn't prevent the focus ring from _ever_ appear, it just
stops it from appearing on first load.
Differential Revision: https://phabricator.services.mozilla.com/D115062
Using autofocus="true" or programmatically calling .focus() when there is no pre-existing focused
element causes the :focus-visible to match.
This patch avoids using autofocus="true" on some of our about: pages, and uses
Element.focus({ preventFocusRing: true }) to avoid that when these pages and dialog
first load. Note that this doesn't prevent the focus ring from _ever_ appear, it just
stops it from appearing on first load.
Differential Revision: https://phabricator.services.mozilla.com/D115062
Awaiting setWindowState doesn't actually work here, since we fire the
SSWindowRestored event before the tabs finish restoring (bug 1709411 to rename
the event). It works to just wait for the individual SSTabRestored events, since
we'll only fire those after each tab is restored.
Differential Revision: https://phabricator.services.mozilla.com/D114261
SessionStore factors both prefs into the decision about if a tab is restored
lazily, but this helper only uses the `restore_tabs_lazily` pref.
Depends on D114001
Differential Revision: https://phabricator.services.mozilla.com/D114002
A previous patch made it so we'd fire this after the full restore finished, but
some consumers expect this event prior to the completion of the load.
Differential Revision: https://phabricator.services.mozilla.com/D114001
This also makes it so that we will never fire SSTabRestored without first having
sent the associated SSTabRestoring event.
Differential Revision: https://phabricator.services.mozilla.com/D110335
With the removal of the SessionStore:RestoreDocShellState message, the epoch
will no longer be updated otherwise, so we should include it in the Flush
message to ensure that messages are not being dropped.
Differential Revision: https://phabricator.services.mozilla.com/D110334
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
With the new "restore docshell state" codepath, we may be calling
updateTabLabelAndIcon() later than we did before, which means we may have
already set the tab label (in tabbrowser.init()), and it's incorrect to override
that label value with the session history entry's title.
Differential Revision: https://phabricator.services.mozilla.com/D111456
This also makes it so that we will never fire SSTabRestored without first having
sent the associated SSTabRestoring event.
Differential Revision: https://phabricator.services.mozilla.com/D110335
With the removal of the SessionStore:RestoreDocShellState message, the epoch
will no longer be updated otherwise, so we should include it in the Flush
message to ensure that messages are not being dropped.
Differential Revision: https://phabricator.services.mozilla.com/D110334
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
We currently wait for the "sessionstore-single-window-restored" notification and
*then* start listening for individual "SSTabRestored" events. This doesn't work
because we may fire those events before we get the chance to create the listener.
Listening for "browser-window-before-show" works consistently, but we need
references to the windows *before* they start restoring, so we have
to manually run the "Restore All Windows" code, instead of clicking the Library
button.
Originally part of the patch stack for bug 1703556.
Differential Revision: https://phabricator.services.mozilla.com/D112887
A document that changes the "multiple" attribute of the <select> element after
the load event (eg., perhaps in response to user action) will crash the browser
since we will attempt to restore data collected for a multi-select into a
single-select.
Differential Revision: https://phabricator.services.mozilla.com/D112057
A document that changes the "multiple" attribute of the <select> element after
the load event (eg., perhaps in response to user action) will crash the browser
since we will attempt to restore data collected for a multi-select into a
single-select.
Differential Revision: https://phabricator.services.mozilla.com/D112057
