This reduces the amount of places where we need to specify the mozilla/frame-script environment. It does have
the side effect of allowing those globals in the whole file, but that is what specifying the environment would
do, and this is also for mochitest test files only.
MozReview-Commit-ID: 1LLFbn6fFJR
When initializing the service in SessionCookies.jsm,
SessionCookies._reloadCookies() currently iterates all cookies held by the
coookie service and calls _updateCookie() to add them. _updateCookie() however
is supposed to deal with cookie modifications, including session cookies being
converted to longer-lived ones, and thus handles deletion too.
This patch ensures a fast startup path by ignoring cookie deletion, we only
ever need to add new session cookies when initializing on startup. It also
changes the "cookie added" notification handler to ignore deletion.
Additionally, CookieStore.delete() is a little more intelligent now and avoids
the creation of maps only to find out the cookie didn't exist after all.
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
This patch includes:
- (By Yoric) Don't collect/save the session when the user is idle;r=mdeboer
- Add a test for the behavior of state writing in idle/active mode
When the user is not actively using the computer, webpages may still
perform changes that require (re)writing to sessionstore, e.g. updating
Session Cookies or DOM Session Storage, or refreshing, etc. Before
this patch, a single active page can require us to
recollect/serialize/write the entire Session Restore file every 15
seconds even when the user is not in front of the computer.
We expect that, when the user is not in front of the computer, changes
are not critical and don't need to be saved as often. We now adopt the
following strategy:
- when the user has been away for (by default) 15 seconds, finish any
pending collect/write, then increase the collect/write buffering
delay to (by default) 1h
- when the user returns, reschedule any pending 1h collect/write as a
(by default) 15 seconds collect/write, then proceed with (by
default) 15 seconds collect/write delays.
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.
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.
This extends the existing the existing scroll position test by navigating to a second page and then checking that after closing and restoring that tab, the scroll position is restored not only for the current history entry, but after going back as well.
MozReview-Commit-ID: Ddig1Mfo5rz
Since a LayoutHistoryState is basically just a collection of PresStates, we just save each PresState we can find and then later restore it.
MozReview-Commit-ID: A6WpdelseHn
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
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
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
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
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
We want to use this for Android, too. Once again, moving the file necessitates fixing a few ESLint errors that weren't yet checked for under the old directory.
MozReview-Commit-ID: IPxcizKwzAX
