This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
Automatic changes by ESLint, except for manual corrections for .xml files.
Differential Revision: https://phabricator.services.mozilla.com/D4439
--HG--
extra : moz-landing-system : lando
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.
PrivacyLevel checks currently allow to disable storing secure cookies and any
cookies belonging to an HTTPS host, or completely disable storing cookies. We
call PrivacyLevel.canSave() for every host found in the shistory of a given
window's tabs. We then call it again for every cookie when retrieving all
cookies stored for a given host.
The two different privacy checks exist because in the past an HTTP site could
send a secure cookie too. Since Firefox 52 this isn’t possible anymore, only
HTTPS sites can send secure cookies. So as soon as nsICookie.isSecure=true
we know the site was loaded over TLS.
That means there are the following scenarios:
[PRIVACY_LEVEL=NONE] (default)
We store all cookies.
[PRIVACY_LEVEL=FULL]
We store no cookies at all.
[PRIVACY_LEVEL=ENCRYPTED]
HTTP site sends cookie: Store.
HTTP site sends secure cookie: Can't happen since Fx52
HTTPS site sends cookie: Store. The site is HTTPS but we should store the
cookie anyway because the "Secure" directive is missing. That means the
site wants us to send it for HTTP requests too.
HTTPS site sends secure cookie: Don't store.
This allows us to simplify the code and remove the per-host PrivacyLevel
checks. Checking nsICookie.isSecure is enough to tell whether we want
to keep a cookie or not.
