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 now create the listener after receiving a "browsing-context-did-set-embedder"
and destroy it after receiving "browsing-context-discarded".
Differential Revision: https://phabricator.services.mozilla.com/D110337
This does a few things:
1. Gets rid of the listener's `_sHistoryChanges` property, which is possible
because _sHistoryChanges == false <-> _fromIdx == kNoIndex.
2. Simplifies the code that interacts with SHistoryListener in
UpdateSessionStoreFromTablistener, and attempts to make that function a
little more readable.
3. Ensures we're only doing the SessionHistory bit of
UpdateSessionStoreFromTablistener for toplevel frames, and if SHIP is
enabled.
Differential Revision: https://phabricator.services.mozilla.com/D110336
We now create the listener after receiving a "browsing-context-did-set-embedder"
and destroy it after receiving "browsing-context-discarded".
Differential Revision: https://phabricator.services.mozilla.com/D110337
This cleans up the SHistoryListener class and does a few things:
1. Gets rid of the listener's `_sHistoryChanges` property, which is possible
because _sHistoryChanges == false <-> _fromIdx == kNoIndex.
2. Simplifies the code that interacts with SHistoryListener in
UpdateSessionStoreFromTablistener, and attempts to make that function a
little more readable.
3. Ensures we're only doing the SessionHistory bit of
UpdateSessionStoreFromTablistener for toplevel frames.
Differential Revision: https://phabricator.services.mozilla.com/D110336
Re-order calls in SessionStore.jsm to invoke the side-effect-free logic
before triggering observable events.
Clear (likely) stale value of the cached currentURI when lazy browsers
are swapped.
And while I was at it, I also fixed a bug that caused a lazy browser to
eagerly be unlazified because the unneeded mute() call on a lazy browser
unlazifies it (discovered when I added complete test coverage for this
change).
Differential Revision: https://phabricator.services.mozilla.com/D108260
Instead of collecting data from the entire tree of documents, we
collect data per document. The collected data is sent to the
corresponding parent window context and is applied incrementally to
the tab state cache.
Differential Revision: https://phabricator.services.mozilla.com/D107814
Instead of collecting data from the entire tree of documents, we
collect data per document. The collected data is sent to the
corresponding parent window context and is applied incrementally to
the tab state cache.
Differential Revision: https://phabricator.services.mozilla.com/D107814
In bug 1589102, changes were made to how about:blank and about:srcdoc load,
making them go via DocumentChannel and thus slightly increasing documents' load
times. This causes some timing issues in SessionStore code.
When we click to "Reopen all (closed) Windows", undoCloseWindow() is called for
each window that we have to restore. The following scenario can occur - we are
restoring window 1, and undoCloseWindow() has already called restoreWindows,
after receiving the window showing promise, and in the meantime
undoCloseWindow() has been called for window 2, and there is now a promise in
the WINDOW_SHOWING_PROMISES. But now restoreWindows() for window1 calls
_openWindows(), where root.windows length is 0, but WINDOW_SHOWING_PROMISES is
not empty (because of window 2's undoCloseWindow), and the resolve callback for
_openWindows() gets called with wrong arg. To solve this, ensure that the
promises returned from _openWindows() correspond to the windows opened
within the body of the function.
Differential Revision: https://phabricator.services.mozilla.com/D106304
### Story
When a COOP+COEP page is opened, we change the remoteness of the tab. After
changing the remoteness, the tab is then restored by its TabState. However,
we haven't collected userContextId through the current mechanism.
To fix that, this patch changes the way to collect userContextId.
### Test Plan
Test: D98296
Depends on D98296
Differential Revision: https://phabricator.services.mozilla.com/D98468
### Story
When a COOP+COEP page is opened, we change the remoteness of the tab. After
changing the remoteness, the tab is then restored by its TabState. However,
we haven't collected userContextId through the current mechanism.
To fix that, this patch changes the way to collect userContextId.
### Test Plan
Test: D98296
Depends on D98296
Differential Revision: https://phabricator.services.mozilla.com/D98468
This formed the backbone of the previous process switching codepath, and
shouldn't be necessary anymore thanks to DocumentChannel's new codepath.
This also removes the eager process switching logic from frontend's _loadURI, as
it would rarely be taken, unless an invalid URI was entered, already.
Differential Revision: https://phabricator.services.mozilla.com/D94639
This formed the backbone of the previous process switching codepath, and
shouldn't be necessary anymore thanks to DocumentChannel's new codepath.
This also removes the eager process switching logic from frontend's _loadURI, as
it would rarely be taken, unless an invalid URI was entered, already.
Differential Revision: https://phabricator.services.mozilla.com/D94639
When seeing DOMTitleChanged in mozilla::dom::TabListener::HandleEvent
or mozilla::dom::ContentSessionStore::{nDocumentStart/OnDocumentEnd}
we should do a full collect of all session history entries in the
parent.
Differential Revision: https://phabricator.services.mozilla.com/D95140
When navigating to a new URL that requires a remoteness change, session store
restores the tab after the change. The restore races the `gURLBar.setURI` call
that happens due to the location change. If the restore happens after the
`setURI` call, then the search mode is "restored" even though a new page was
loaded.
The session store code surrounding the chunk that I modified in bug 1655486
checks for a remoteness change before trying to restore `userTypedValue`. If the
restore is due to a remoteness change, then it doesn't restore `userTypedValue`.
We just need to do the same for search mode.
Also, I think we should be using `TabStateCache` here, not `TabState.collect`.
`TabStateCache` is updated in `restoreTab` and is available throughout the
restore process. `TabState.collect` on the other hand is a live view of the
given tab, so if search mode happens to be active when `collect` is called, then
the returned tab state will have `searchMode` defined, which is not what we want
here. But I'm not sure why the surrounding code here uses `TabState.collect`
instead of `TabStateCache` in order to restore `userTypedValue`. It seems like
an error to me, but I might be missing something.
Due to the racey nature of this bug, writing a test isn't so easy, so this patch
doesn't have one. It will be obvious through manual testing if this regresses.
Differential Revision: https://phabricator.services.mozilla.com/D93455
* Always update the `_searchModesByBrowser` map when entering/exiting search
mode, not only for non-selected browsers, so that search mode can be saved and
restored properly per tab.
* Rename `setSearchMode` to `_updateSearchModeUI` and make it only update the UI.
* Add a new `setSearchMode` method that takes a browser and updates the map.
* Add `getSearchMode` so that SessionStore can get the search mode for a given
browser.
* Add a `searchMode` getter and setter for convenience. They call
`getSearchMode` and `setSearchMode` with the selected browser.
Differential Revision: https://phabricator.services.mozilla.com/D91910
