Current state:
--------------
Session cookies - those that have no Expires or Max-Age directive, sent as a
header or set via document.cookie - are meant to live for the duration of a
session. SessionStore is a feature that aims to enable users to resume where
they left off last time they closed the browser. So SessionStore will persist
and restore those cookies that the cookie service only keeps in memory.
SessionCookies.jsm registers observers with the cookie service and is thus
notified of cookie additions, deletions, and modifications as-it-happens. It
has its own internal storage that we could easily serialize and write to disk
together with the rest of the session data.
The hangs shown in various profiles stem from the fact that since the inception
of SessionStore as an add-on around Firefox 2, cookies have been tacked to
windows. This means that whenever we collect session data for a specific
window (i.e. tabs, their shistory entries, etc.) we have to iterate *all* its
tabs and *all* their shistory entries to enumerate the hosts contained in that
window. We will then ask the internal cookie store in SessionCookies.jsm to
give us all cookies for these hosts and then store them together with the
window. This way we filter out cookies from tabs/hosts that have no active
documents (BFCache counts as "active").
Changes in this patch:
----------------------
Instead of trying to only retain cookies from “active” documents, i.e. those
contained somewhere in the shistory of a tab, we now simply save all session
cookies of the session. This will surely reduce user complaints about us
"logging them out" too fast because we discard cookies from tabs they
open only once in a while, although those definitely belong to the
browsing session.
Instead of storing the cookies per each window we now have a top-level
"cookies" attribute that is a list of cookies. These get restored whenever we
restore a session. Legacy window.cookies attributes will still be restored to
support older session formats for a while.
The DEFER_SESSION startup mode is active by default when a user choses not to
restore their whole session automatically but they still have one or more
pinned tabs. These pinned tabs are restored automatically and split off of the
rest of the session. The rest can be restored manually if the user chooses to
do so.
In the past, we here extracted and restored only the pinned tabs' cookies from
the last session. This filtering also works against how some sites (e.g.
Google) use session cookies. It also means we have to iterate all windows,
tabs, shistory entries, and cookies to find the data we want.
This patch changes our past behavior so that we now restore only pinned tabs
but all session cookies. So we don't have to filter, and pages will break less
likely. We hereby assume that a user having pinned tabs wants to continue their
browsing session partially, although without Firefox remembering the exact list
of tabs. Or they simply like starting off of a clean slate.
When restoring a window, it's cheaper if we move the initially selected tab to the
index of the tab that's supposed to be selected in the restored state, rather than
switching to that tab.
If it turns out that moving that tab is not possible (if, for example, the user
context IDs of the two tabs to swap don't match, since the userContextIds are
set at tab construction time), then we fall back to tab switching.
MozReview-Commit-ID: L3qP40K5DaJ
--HG--
extra : rebase_source : 0954dac2f17af74418817ed45c5ab5dee7796511
The first change we can make is to simplify the PrivacyLevel.canSave() method
itself as it only takes a single argument, `isHTTPS`. Callers shouldn't be
required to pass an object, they should simply pass a boolean.
The second change here is to cleanup SessionCookies.jsm that still passes the
old `isPinned` argument that's no longer needed. We can remove some house
keeping and simplify the cookie collection code.
SessionCookies.getHostsForWindow() that previously returned a map from hostnames
to a site's pinned status (tab.pinned) can now simply return a Set containing
all hostnames found in a window.
Running eslint with --fix didn't fix many of the issues. The majority here had to be fixed by hand but a significant majority of the issues were related to a few files that I was able to use find-and-replace with. I regret not making this in to separate commits of the hand-fixes and the fixes from --fix but I don't recall --fix fixing any of the issues.
MozReview-Commit-ID: ANyg2qfo3Qx
--HG--
extra : rebase_source : 61d2aa91bf9474af3d72a5dea41b25dca442c1b7
Originally, we were forcing these restored background tabs to be non-remote by default.
This was because we didn't want them to show the crashed tab favicon nor show about:tabcrashed
if the user hadn't restored them before.
Bug 1241459 added infrastructure that makes it possible to put crashed background tabs into
the "restore on demand" state again, without showing about:tabcrashed or showing the crashed
tab favicon.
This means we should be able to restore tabs in the content process again which should take
some load off of the parent process during session restore, which is good for perceived
performance.
Note that if the content process does crash, the background tabs are then loaded in the parent
process. Restoring them on demand will then do the remoteness flip.
MozReview-Commit-ID: 1mWe0td6geB
--HG--
extra : rebase_source : ea872b615ebe3d8639b214bfafc5e358ba6e65fd
This helps differentiate restorations that were caused by navigateAndRestore, as opposed
to SessionStore having set state via setBrowserState, setWindowState, or setTabState.
MozReview-Commit-ID: DEEbKLh7f7p
--HG--
extra : rebase_source : c48ab225d17128041ccbde4e5cc8c87899166b9e
Originally, we were forcing these restored background tabs to be non-remote by default.
This was because we didn't want them to show the crashed tab favicon nor show about:tabcrashed
if the user hadn't restored them before.
Bug 1241459 added infrastructure that makes it possible to put crashed background tabs into
the "restore on demand" state again, without showing about:tabcrashed or showing the crashed
tab favicon.
This means we should be able to restore tabs in the content process again which should take
some load off of the parent process during session restore, which is good for perceived
performance.
Note that if the content process does crash, the background tabs are then loaded in the parent
process. Restoring them on demand will then do the remoteness flip.
MozReview-Commit-ID: 1mWe0td6geB
--HG--
extra : rebase_source : 5e1dbbaf0e1fb641bd43f821980ab5dff7272b04
This helps differentiate restorations that were caused by navigateAndRestore, as opposed
to SessionStore having set state via setBrowserState, setWindowState, or setTabState.
MozReview-Commit-ID: DEEbKLh7f7p
--HG--
extra : rebase_source : 7fa68acf1ffd85f28af2be9c00f2ef65b21375f6
This patch adds userTypedValue data validation when saving tabs to disk
MozReview-Commit-ID: EltANtbDfqe
--HG--
extra : rebase_source : f1e6b9a3afecfbdacd66716b335695a3bcad255e
This patch creates a new method that verifies if the tab state we're passed is
something we should keep to be reopened at session restore. This is used when
we are saving the current session state to disk. This method is very similar to
_shouldSaveTabState, however, "about:blank" and "about:newtab" tabs will still
be saved to disk.
MozReview-Commit-ID: 70zKFeUG9uQ
--HG--
extra : rebase_source : 994412066334f7a1e85707a011225d7c5b65c319
A check for the customizemode attribute was added to SessionStore.restoreTabContent
back when we removed the about:customizing preloading hackery in bug 1014185. This
was added to prevent the extra work of unnecessarily restoring the content for a
tab that was in customize mode (since the content is actually hidden).
However, there are ways for a user to attempt to browse away from customize mode
in the current tab - for example, going to their Home page with Alt-Home. When
we do this in e10s mode, we do a "remoteness flip" to make the hidden about:blank
browser be remote, which causes us to go through the SessionStore machinery to
do the session swap to the new remote browser. The problem is when we hit the
restoreTabContent part - we hit the condition where the customizemode attribute
is set to true, and then we bail out, which means we never finish the swap. We're,
at this point, in a half-restored state that never resolves.
This patch makes it so that in restoreTabContent, if loadArguments is not null (so
we've been given arguments on where to send the browser _next_ on top of its newly
restored history), we don't skip just because the customizemode attribute is set.
MozReview-Commit-ID: HwW7y2EKJvn
--HG--
extra : rebase_source : 73dfebae4f0399905a8146545618e62826817df0
