The tests in browser_tabCloseProbes.js were closing tabs without waiting for them
to be fully open, and when they're not fully open, closing occurs without animation.
This was intermittently breaking the test for the probe that checks that we add
a count to the right histogram when closing with animation.
MozReview-Commit-ID: 5Qz7mZvtbkB
--HG--
extra : rebase_source : 0d794faebc8e751bfcd15476ae849018dfb1f6c1
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.
There are quite a few changes in here. At a high level, all we're trying to do is to replace the old update popup with a less intrusive and more modern doorhanger (set of doorhangers) for various update success and failure conditions.
There are quite a few changes in here. At a high level, all we're trying to do is to replace the old update popup with a less intrusive and more modern doorhanger (set of doorhangers) for various update success and failure conditions.
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
--HG--
extra : rebase_source : 82a6934d90bbbbd25f91b7b06bf4f9354e38865a
When font.name.*.* is set to false, "value" attribute of <preference> is removed. Then, <preference>.setElementValue() with an element which doesn't have onsyncfrompreference tries to set null. Then, <menulist> selects nothing.
In such case, <menulist> should select the item whose value is "". If there is onsyncfrompreference attribute and it returns empty string, <preference>.setElementValue() works as expected.
MozReview-Commit-ID: 54KIe3JxwyA
--HG--
extra : rebase_source : 8b94ff9a790cb5f771901cbfea72240d6d8df554
Update also the similar logic in browser/installer/package-manifest.in. The
reason I added the symbolizer is because it'd be useful when someone conduct
jsshell testing/fuzzing.
MozReview-Commit-ID: J9IqFWsnskS
--HG--
extra : rebase_source : db461065f778fc025576b1fc7612642181d94dcd
There's quite a few changes in here. At a high level, all we're trying to do
is to replace the old update popup with a less intrusive and more modern
doorhanger (set of doorhangers) for various update failure conditions.
MozReview-Commit-ID: 24sESMTosNX
--HG--
extra : rebase_source : ee0c1e00fe3f99e16388f0de17274ff97a3b9fcf
It isn't needed until we create a context menu.
MozReview-Commit-ID: 4kCfq9PzVPV
--HG--
extra : rebase_source : 51907d6aa28d5bd2a9fb8a0acb28cac719888292
This avoids importing ContentWebRTC.jsm unless webrtc is actually
being used, which reduces memory usage.
MozReview-Commit-ID: GlMo1WIZEFD
--HG--
extra : rebase_source : 25476c825bef1948f22d0e6dae67dc01ab41f886
This avoids importing ContentWebRTC.jsm just to register observers
that may never observe anything. Avoiding importing .jsms reduces
memory usage.
ContentObserver.js gets loaded once per content process, so I think
the ._initialized stuff is not needed in the process script.
MozReview-Commit-ID: 5r9L3bfFS0U
--HG--
extra : rebase_source : 0fe6e14c2963efccf21bd1606885098902fed598
The tests in browser_tabCloseProbes.js were closing tabs without waiting for them
to be fully open, and when they're not fully open, closing occurs without animation.
This was intermittently breaking the test for the probe that checks that we add
a count to the right histogram when closing with animation.
MozReview-Commit-ID: 5Qz7mZvtbkB
--HG--
extra : rebase_source : 3533f2c43091829723463f8943cf43e722bbd70c
The .app directory for OSX builds is created piecemeal by several
commands in browser/app/Makefile.in, however it isn't normally cleaned
by a build. If a file is removed from the tree, it's possible that an
incremental build will still have a copy in the .app dir and get
packaged up in the final dmg. It's simple to just rm -rf this directory
beforehand.
MozReview-Commit-ID: 2Zr97o9dTn8
--HG--
extra : rebase_source : 2c9995991c58ee9724464514ec8285c31ab8d062
This avoids a sync IPC message from child to parent.
Changes entirely from:
https://github.com/mozilla/pdf.js/pull/8218
MozReview-Commit-ID: 3Egayok3DBZ
--HG--
extra : rebase_source : e02829e2508bb75caf44c0a3c86b06fac3bf167f
One is always run, the other is only run when PdfJs.enabled is true in
the parent process. This refactoring enables the next patch.
The extensions changes are from:
https://github.com/mozilla/pdf.js/pull/8218
MozReview-Commit-ID: HwQ3yk8Jck4
--HG--
extra : rebase_source : 94f1516989685176a95e235f2d3ef8658adaf8b7
MozReview-Commit-ID: CIrC4ise4Zs
Hotkeys works like normal DOM links, except "Open in background tab" (which corresponds to ctrl/command + click)
open tabs in foreground due to limitation from outside chrome process.
--HG--
extra : rebase_source : 6a3b43c518e23c61fe3c48cc4317b813a39acc7a
