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
This causes the browser to steal focus from any element that was focused prior
to the completion of the remoteness flip. This is particularly a problem for
fission because every cross-origin navigation requires a process switch.
This code is still necessary for "normal" session restores (see bug 1410591),
but focus is handled elsewhere for remote navigations.
Differential Revision: https://phabricator.services.mozilla.com/D82783
This causes the browser to steal focus from any element that was focused prior
to the completion of the remoteness flip. This is particularly a problem for
fission because every cross-origin navigation requires a process switch.
This code is still necessary for "normal" session restores (see bug 1410591),
but focus is handled elsewhere (and more robustly) for navigations.
Differential Revision: https://phabricator.services.mozilla.com/D82783
This patch removes the excemptions for about:newtab, about:home and
about:blank.
When we switch processes using session restore we sometimes focus the
content area. We mustn't do this if the uri is undefined, this can happen
for some of these pages and we expect the address bar to be focused instead.
Differential Revision: https://phabricator.services.mozilla.com/D80339
These were only used by process switches triggered via DocumentChannel, which
now take the PROCESS_BEHAVIOR_STANDARD codepath.
Differential Revision: https://phabricator.services.mozilla.com/D78973
Add a series of extra hooks and methods to allow tabbrowser to use the new
process switching codepath. This duplicates some of the logic from
`updateBrowserRemoteness` into event handlers.
Differential Revision: https://phabricator.services.mozilla.com/D78970
These were only used by process switches triggered via DocumentChannel, which
now take the PROCESS_BEHAVIOR_STANDARD codepath.
Differential Revision: https://phabricator.services.mozilla.com/D78973
Add a series of extra hooks and methods to allow tabbrowser to use the new
process switching codepath. This duplicates some of the logic from
`updateBrowserRemoteness` into event handlers.
Differential Revision: https://phabricator.services.mozilla.com/D78970
When I first added this method last year, I added it in JS, handled from within
SessionStore.jsm, as that was the easiest place to do it. Now that
DocumentLoadListener exists, it makes more sense to handle this logic directly
from within that code.
Many parts of the process switch are still handled by frontend JS, such as
selecting remote types, and performing toplevel process switches.
Differential Revision: https://phabricator.services.mozilla.com/D68594
When I first added this method last year, I added it in JS, handled from within
SessionStore.jsm, as that was the easiest place to do it. Now that
DocumentLoadListener exists, it makes more sense to handle this logic directly
from within that code.
Many parts of the process switch are still handled by frontend JS, such as
selecting remote types, and performing toplevel process switches.
Differential Revision: https://phabricator.services.mozilla.com/D68594
When I first added this method last year, I added it in JS, handled from within
SessionStore.jsm, as that was the easiest place to do it. Now that
DocumentLoadListener exists, it makes more sense to handle this logic directly
from within that code.
Many parts of the process switch are still handled by frontend JS, such as
selecting remote types, and performing toplevel process switches.
Differential Revision: https://phabricator.services.mozilla.com/D68594
