When an extension does call tabs.discard earlier in the tab creation (e.g. when the extension calls
tabs.discard from inside a tabs.onUpdated listener), when the tab is activated (e.g. by selecting
the non-currently active lazified tab) Firefox is expected to restore it to the webpage url that
was being loaded.
This was already working as expected on non-private tabs, where the expected tab url was stored
in the TabStateCache as the userTypedValue (which seems to be part of a fix also related to
tabs.discard and landed in Firefox 62 from Bug 1422588).
It didn't work yet for private tabs, because for a private tab we are storing `{isPrivate: true}`
into the TabStateCache as soon as we are creating the tab, and so the change to SessionStore
resetBrowserToLazyState applied from Bug 1422588 had no effect for the private tabs
(due to the check for an existing cached entry for the same tab).
This patch applies a small change to ensure we are caching the userTypedValue set on the browser
element if one is not already stored in the TabStateCache, and adds an additional test case
to browser_ext_tabs_discarded.js which cover the expected behavior (and fails as expected
without a fix for the underlying issue).
Differential Revision: https://phabricator.services.mozilla.com/D122370
This fails in promiseOnHistoryReplaceEntry since the browser goes away before
the SpecialPowers task can resolve. This doesn't apply to SHIP since we listen
for history events in the parent instead for that.
Differential Revision: https://phabricator.services.mozilla.com/D122486
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
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
The effect of this bug should be a slow leak of unreferenced cache entries
between sessions. After the fix we should just be appropriately cleaning them
up.
Differential Revision: https://phabricator.services.mozilla.com/D121644
The effect of this bug should be a slow leak of unreferenced cache entries
between sessions. After the fix we should just be appropriately cleaning them
up.
Differential Revision: https://phabricator.services.mozilla.com/D121644
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
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
Read this as a first step. It's the easiest first step I could think of to
both reduce the quantity of stuff we serialize and ship to the worker as
well as to spread it out over multiple messages.
Anyway, the motivation is pretty simple. Taking a look at a session store
file on disk, a giant chunk of it is base64 encoded tab icons. I suspect
that in many cases these are not distinct. For my session store it's about
90% the same repeated searchfox icon over and over.
So what I did was I changed the "image" property of the tab to be a reference
into a deduplicated cache of objects (in this case strings). Whenever the tab
icon changes, we drop a reference to its cache entry and add a reference to a
new or existing entry. Each time a cache entry is added or deleted, we send
a message to the worker to update its own copy of the cache. This does
represent a memory hit, since the cache is maintained on the worker as well as
the main thread, but I think it's going to be minor, and it's only in one
process. Given the deduplication there is the possibility of an overall
reduction in memory use? This needs more testing.
Once it comes time to write the session data to disk, we send the payload with
"image" entries referencing IDs in the cache. When the worker gets the message
to write, it adds its internal cache to the object, which it then serializes
to JSON and writes to disk as usual.
When reading the data off disk, we take the cache items that had been written
and we slowly populate the worker's internal cache with them (to not overload
during startup with a giant message). And when populating tab icons of tabs in
the tab strip, we look up the image in the main thread copy of the cache. Also,
if we cannot find the entry, we assume that the image is just the raw
representation of the image. This ensures that we interpret a sessionstore file
from prior to this patch correctly.
Additionally, since we have the cache duplicated on both threads, if the worker
gets terminated for some reason, we rehydrate it with the snapshot of the cache
from when we noticed it was a problem.
I suspect some tests will need to be updated, or maybe many tests. However I
wanted to throw this patch past someone with more knowledge of the session
store's inner workings before throwing a bunch of time at that.
Differential Revision: https://phabricator.services.mozilla.com/D114196
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
