gecko-dev/browser/components/sessionstore/SessionCookies.jsm

270 строки
6.5 KiB
JavaScript
Исходник Обычный вид История

/* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this file,
* You can obtain one at http://mozilla.org/MPL/2.0/. */
"use strict";
this.EXPORTED_SYMBOLS = ["SessionCookies"];
const Cu = Components.utils;
const Ci = Components.interfaces;
Cu.import("resource://gre/modules/Services.jsm", this);
Cu.import("resource://gre/modules/XPCOMUtils.jsm", this);
XPCOMUtils.defineLazyModuleGetter(this, "Utils",
"resource://gre/modules/sessionstore/Utils.jsm");
XPCOMUtils.defineLazyModuleGetter(this, "PrivacyLevel",
"resource://gre/modules/sessionstore/PrivacyLevel.jsm");
// MAX_EXPIRY should be 2^63-1, but JavaScript can't handle that precision.
const MAX_EXPIRY = Math.pow(2, 62);
/**
* The external API implemented by the SessionCookies module.
*/
this.SessionCookies = Object.freeze({
Bug 912717 - Don't let SessionCookie collection jank the chrome process r=mikedeboer 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.
2017-04-07 15:41:38 +03:00
collect() {
return SessionCookiesInternal.collect();
},
restore(cookies) {
SessionCookiesInternal.restore(cookies);
}
});
/**
* The internal API.
*/
var SessionCookiesInternal = {
/**
* Stores whether we're initialized, yet.
*/
_initialized: false,
/**
Bug 912717 - Don't let SessionCookie collection jank the chrome process r=mikedeboer 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.
2017-04-07 15:41:38 +03:00
* Retrieve an array of all stored session cookies.
*/
Bug 912717 - Don't let SessionCookie collection jank the chrome process r=mikedeboer 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.
2017-04-07 15:41:38 +03:00
collect() {
this._ensureInitialized();
Bug 912717 - Don't let SessionCookie collection jank the chrome process r=mikedeboer 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.
2017-04-07 15:41:38 +03:00
return CookieStore.toArray();
},
/**
* Restores a given list of session cookies.
*/
restore(cookies) {
for (let cookie of cookies) {
let expiry = "expiry" in cookie ? cookie.expiry : MAX_EXPIRY;
let cookieObj = {
host: cookie.host,
path: cookie.path || "",
name: cookie.name || ""
};
Bug 912717 - Don't let SessionCookie collection jank the chrome process r=mikedeboer 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.
2017-04-07 15:41:38 +03:00
let originAttributes = cookie.originAttributes || {};
if (!Services.cookies.cookieExists(cookieObj, originAttributes)) {
Services.cookies.add(cookie.host, cookie.path || "", cookie.name || "",
cookie.value, !!cookie.secure, !!cookie.httponly,
Bug 912717 - Don't let SessionCookie collection jank the chrome process r=mikedeboer 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.
2017-04-07 15:41:38 +03:00
/* isSession = */ true, expiry, originAttributes);
}
}
},
/**
* Handles observers notifications that are sent whenever cookies are added,
* changed, or removed. Ensures that the storage is updated accordingly.
*/
observe(subject, topic, data) {
switch (data) {
case "added":
this._addCookie(subject);
break;
case "changed":
this._updateCookie(subject);
break;
case "deleted":
this._removeCookie(subject);
break;
case "cleared":
CookieStore.clear();
break;
case "batch-deleted":
this._removeCookies(subject);
break;
default:
throw new Error("Unhandled cookie-changed notification.");
}
},
/**
* If called for the first time in a session, iterates all cookies in the
* cookies service and puts them into the store if they're session cookies.
*/
_ensureInitialized() {
if (!this._initialized) {
this._reloadCookies();
this._initialized = true;
Services.obs.addObserver(this, "cookie-changed");
Bug 912717 - Don't let SessionCookie collection jank the chrome process r=mikedeboer 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.
2017-04-07 15:41:38 +03:00
// Listen for privacy level changes to reload cookies when needed.
Services.prefs.addObserver("browser.sessionstore.privacy_level", () => {
this._reloadCookies();
});
}
},
/**
* Adds a given cookie to the store.
*/
_addCookie(cookie) {
cookie.QueryInterface(Ci.nsICookie2);
Bug 912717 - Don't let SessionCookie collection jank the chrome process r=mikedeboer 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.
2017-04-07 15:41:38 +03:00
// Store only session cookies, obey the privacy level.
if (cookie.isSession && PrivacyLevel.canSave(cookie.isSecure)) {
CookieStore.add(cookie);
}
},
/**
* Updates a given cookie.
*/
_updateCookie(cookie) {
cookie.QueryInterface(Ci.nsICookie2);
Bug 912717 - Don't let SessionCookie collection jank the chrome process r=mikedeboer 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.
2017-04-07 15:41:38 +03:00
// Store only session cookies, obey the privacy level.
if (cookie.isSession && PrivacyLevel.canSave(cookie.isSecure)) {
CookieStore.add(cookie);
} else {
CookieStore.delete(cookie);
}
},
/**
* Removes a given cookie from the store.
*/
_removeCookie(cookie) {
cookie.QueryInterface(Ci.nsICookie2);
if (cookie.isSession) {
CookieStore.delete(cookie);
}
},
/**
* Removes a given list of cookies from the store.
*/
_removeCookies(cookies) {
for (let i = 0; i < cookies.length; i++) {
this._removeCookie(cookies.queryElementAt(i, Ci.nsICookie2));
}
},
/**
* Iterates all cookies in the cookies service and puts them into the store
Bug 912717 - Don't let SessionCookie collection jank the chrome process r=mikedeboer 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.
2017-04-07 15:41:38 +03:00
* if they're session cookies. Obeys the user's chosen privacy level.
*/
_reloadCookies() {
Bug 912717 - Don't let SessionCookie collection jank the chrome process r=mikedeboer 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.
2017-04-07 15:41:38 +03:00
CookieStore.clear();
// Bail out if we're not supposed to store cookies at all.
if (!PrivacyLevel.canSave(false)) {
return;
}
let iter = Services.cookies.enumerator;
while (iter.hasMoreElements()) {
this._addCookie(iter.getNext());
}
}
};
/**
Bug 912717 - Don't let SessionCookie collection jank the chrome process r=mikedeboer 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.
2017-04-07 15:41:38 +03:00
* The internal storage that keeps track of session cookies.
*/
var CookieStore = {
/**
Bug 912717 - Don't let SessionCookie collection jank the chrome process r=mikedeboer 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.
2017-04-07 15:41:38 +03:00
* The internal map holding all known session cookies.
*/
Bug 912717 - Don't let SessionCookie collection jank the chrome process r=mikedeboer 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.
2017-04-07 15:41:38 +03:00
_entries: new Map(),
/**
* Stores a given cookie.
*
* @param cookie
* The nsICookie2 object to add to the storage.
*/
Bug 912717 - Don't let SessionCookie collection jank the chrome process r=mikedeboer 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.
2017-04-07 15:41:38 +03:00
add(cookie) {
let jscookie = {host: cookie.host, value: cookie.value};
// Only add properties with non-default values to save a few bytes.
if (cookie.path) {
jscookie.path = cookie.path;
}
if (cookie.name) {
jscookie.name = cookie.name;
}
if (cookie.isSecure) {
jscookie.secure = true;
}
if (cookie.isHttpOnly) {
jscookie.httponly = true;
}
if (cookie.expiry < MAX_EXPIRY) {
jscookie.expiry = cookie.expiry;
}
if (cookie.originAttributes) {
jscookie.originAttributes = cookie.originAttributes;
}
Bug 912717 - Don't let SessionCookie collection jank the chrome process r=mikedeboer 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.
2017-04-07 15:41:38 +03:00
this._entries.set(this._getKeyForCookie(cookie), jscookie);
},
/**
* Removes a given cookie.
*
* @param cookie
* The nsICookie2 object to be removed from storage.
*/
delete(cookie) {
Bug 912717 - Don't let SessionCookie collection jank the chrome process r=mikedeboer 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.
2017-04-07 15:41:38 +03:00
this._entries.delete(this._getKeyForCookie(cookie));
},
/**
* Removes all cookies.
*/
clear() {
Bug 912717 - Don't let SessionCookie collection jank the chrome process r=mikedeboer 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.
2017-04-07 15:41:38 +03:00
this._entries.clear();
},
/**
* Return all cookies as an array.
*/
toArray() {
return [...this._entries.values()];
},
/**
Bug 912717 - Don't let SessionCookie collection jank the chrome process r=mikedeboer 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.
2017-04-07 15:41:38 +03:00
* Returns the key needed to properly store and identify a given cookie.
* A cookie is uniquely identified by the combination of its host, name,
* path, and originAttributes properties.
*
* @param cookie
Bug 912717 - Don't let SessionCookie collection jank the chrome process r=mikedeboer 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.
2017-04-07 15:41:38 +03:00
* The nsICookie2 object to compute a key for.
* @return string
*/
Bug 912717 - Don't let SessionCookie collection jank the chrome process r=mikedeboer 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.
2017-04-07 15:41:38 +03:00
_getKeyForCookie(cookie) {
return JSON.stringify({
host: cookie.host,
name: cookie.name,
path: cookie.path,
attr: ChromeUtils.originAttributesToSuffix(cookie.originAttributes)
});
}
};