Previously we've removed data from the session store that aren't
currently in the current browsing context tree, but this is different
from what BackgroundSessionStorageManager considers to be a
session. After part 1 in this patch series, session store will save
exactly the view BackgroundSessionStorageManager has of the current
sessionStorage state.
Differential Revision: https://phabricator.services.mozilla.com/D125681
These tests are excluded from android test runs in moz.build. Including
an explicit annotation in each manifest avoids scheduling confusion.
browser-chrome and plain-chrome tests in browser/ are of no concern,
since those test types are never scheduled on android.
Differential Revision: https://phabricator.services.mozilla.com/D125266
We currently only block shutdown on flushes for windows that appear in the
BrowserWindowTracker.orderedWindows list, which may or may not include the most
recent window (this appears to depend on _how_ the window was closed). Including
windows for which we saw "domwindowclosed" means that we'll also wait on flushes
for the most recent window.
This also ensures that we're queuing a SessionStoreUpdate from TabListener on
STATE_START/STATE_STOP (as ContentSessionStore.jsm does), and fixes a bug where
we were trying to remove an observer with the `deferred.reject` callback,
instead of the actual observer.
Differential Revision: https://phabricator.services.mozilla.com/D124403
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
