This change makes all browsers which were not created with an initial `remote`
attribute within a non-`useRemoteTabs` window be unable to process-switch, as
otherwise we may attempt to switch loads into a content process. We need to
keep process switching enabled for explicitly-remote browsers loaded in a
non-`useRemoteTabs` window as it's relied on for tests and can lead to
assertion failures due to loading remote content in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D121285
This change makes all browsers which were not created with an initial `remote`
attribute within a non-`useRemoteTabs` window be unable to process-switch, as
otherwise we may attempt to switch loads into a content process. We need to
keep process switching enabled for explicitly-remote browsers loaded in a
non-`useRemoteTabs` window as it's relied on for tests and can lead to
assertion failures due to loading remote content in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D121285
This change makes all browsers which were not created with an initial `remote`
attribute within a non-`useRemoteTabs` window be unable to process-switch, as
otherwise we may attempt to switch loads into a content process. We need to
keep process switching enabled for explicitly-remote browsers loaded in a
non-`useRemoteTabs` window as it's relied on for tests and can lead to
assertion failures due to loading remote content in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D121285
This change makes all browsers which were not created with an initial `remote`
attribute within a non-`useRemoteTabs` window be unable to process-switch, as
otherwise we may attempt to switch loads into a content process. We need to
keep process switching enabled for explicitly-remote browsers loaded in a
non-`useRemoteTabs` window as it's relied on for tests and can lead to
assertion failures due to loading remote content in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D121285
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
The new histogram `TAB_UNLOAD_TO_RELOAD` records how long a tab had been
unloaded until it was reload by a user. With this data, we can evaluate
the selection logic to choose a tab to unload. For example, if many of
unloaded tabs are reloaded within 30 seconds or so, we unload a wrong tab.
Differential Revision: https://phabricator.services.mozilla.com/D120019
This involves changing moveToAnchor to be allowed while the popup is showing. This change allows the buttons within the tab to use the normal algorithm for determining the tooltip position. This also fixes bug 1695900 so that tooltips for items in bookmarks menus also appear offset as well. Only the main tab and bookmarks on the toolbar appear aligned with the button's bottom edge.
Differential Revision: https://phabricator.services.mozilla.com/D115558
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
`swapBrowsersAndCloseOther` calls `SessionStore.setTabState`, but the
latter may trigger several tab events before the tab has fully been
restored. This results in duplicate tabs.onUpdated events and in
unexpected access to properties of the tab/browser (which in turn
triggers the reported bug).
Fix this specific case by ignoring events that happen while the tab is
amidst a restoration.
Differential Revision: https://phabricator.services.mozilla.com/D108259
The SpinEventLoopUntilOrShutdown is interrupted in the main process only at stage "xpcom-shutdown", which is too late. In a content process instead we interrupt it early enough, at "content-child-will-shutdown".
This patch removes the current observer logic in nsThreadManager in favor of a current shutdown phase state machinery in AppShutdown and renames SpinEventLoopUntilOrShutdown to SpinEventLoopUntilOrQuit. It also ensures that SpinEventLoopUntilOrQuit breaks early (at "quit-application" in the main process).
For a further possible cleanup around shutdown state in child and parent process please refer to bug 1697745.
We have no automated test for this edge case, but we have diagnostic telemetry that will tell us if it helps.
Differential Revision: https://phabricator.services.mozilla.com/D107619
