FX_SESSION_RESTORE_COLLECT_DATA_LONGEST_OP_MS can go because that's exactly the same as FX_SESSION_RESTORE_COLLECT_DATA_MS now.
We can remove FX_SESSION_RESTORE_COLLECT_COOKIES_MS because that's just a flat line since bug 912717 landed.
Opening pages in a new tab might suffer an extra delay from e10s-multi because
the new process has to start up and then run all the process / frame scripts
before it can react on the request from the parent to load the first page.
There are two code paths. Either we start the tab with a remote browser and
then the RemoteWebNavigation will send the request. Or we start with a non-remote
browser and have to change the remoteness flag on it, and then the SessionStore
will send the request.
In each cases we start the timer on the parent side, send it with the message,
and when the child receives it it stops the timer and reports the measured delay.
Since bug 912717 the cookies moved from state.windows[x].cookies (i.e. stored
per-window) to state.cookies (i.e. one global list of cookies). We forgot to
update the code in SessionSaver._saveState() that purges cookies upon clean
shutdown if requested by the user's preferences.
Bug 588482 made it possible to restore pinned tabs in windows before restoring the rest of the
tabs. Part of this involves extracting the pinned tab data from the last session, and make it
the default state to restore. The rest can be restored later.
If one of the pinned tabs in a window were selected, the code that was preparing the default
state for that window set the selection value by calculating the length of the tabs array
(before adding the selected one), and adding 2. Presumably, 1 count is because of the tab
we're about to add, and another count is due to how the "selected" value in SessionStore
is 1-indexed (where "0" means, "don't change the selection").
This is an off-by-one error though, since the tabs array length already cancels out the
need for the extra "1-index" difference. It is sufficient to just add 1 to the length of
the tabs array to calculate the selected value.
This appears to have been a bug for a while, but was covered up by the fact that the old
tab selection code exited early if the 0-indexed value of the selected tab was not within
the length of the tabs array. Bug 1351677 uncovered this bug by removing that second check.
This patch fixes the off-by-one error, and also puts a check back in to ensure that the tab
we're going to select is at a valid index.
MozReview-Commit-ID: 9WbbU0vUJHG
This rolls browser.tabs.animate, browser.fullscreen.animate, and
alerts.disableSlidingEffect into a single pref; if any of these are disabled,
we'll disable the new pref too (toolkit.cosmeticAnimations.enabled). Most
future animations will also be subject to this pref.
MozReview-Commit-ID: 77pLMtERDna
The browser.contentPrincpal will report a null prinicpal instead of the actual
content principal if the tab is not loaded. So the SessionStore will collect a
wrong principal for the 'iconLoadingPrincipal', and it will use this wrong
principal to load favicon when session restoring.
To fix this problem, this patch makes the TabState.jsm to collect
'iconLoadingPrincipal' from browser.mIconLoadingPrincipal which will be the
correct principal for loading favicon.
MozReview-Commit-ID: AYUbHFKaG8v
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.
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
