This is a backout of Bug 1347791 part 4; 49b533231388.
49b533231388 took the mediaBlocked attribute and stored it in session store,
and caused us to call browser.resumeMedia() or blockMedia() as appropriate
upon restore. We don't want to session restore whether tabs have had delay
playback start unblocked anymore, so remove the code that session stores
that attribute.
MozReview-Commit-ID: AkRVlufrUAK
--HG--
extra : rebase_source : 613619e2ec587b546cede7795b76b049258df9dd
This also removes any redundant Ci.nsISupports elements in the interface
lists.
This was done using the following script:
acecb401b7/processors/chromeutils-generateQI.jsm
MozReview-Commit-ID: AIx10P8GpZY
--HG--
extra : rebase_source : a29c07530586dc18ba040f19215475ac20fcfb3b
NOTE: The '__SSi' and '__SS_lastSessionWindowID' properties on windows are kept,
because they are expected to stick around longer during application shutdown.
The benefits is are:
1. Cleaner code - Sessionstore implementation details are not leaked outside its
module.
2. Observing the lifetime of objects becomes unnecessary, because the WeakMaps are
cleaned up when objects are GC'd, making leakage of their references impossible
and Sessionstore can't hold objects hostage anymore.
3. Simplification - all state is now maintained in SessionStore.jsm, which allows
for additional refactoring later on to simplify the implementation further.
MozReview-Commit-ID: C1II8qHkQ6F
--HG--
extra : rebase_source : e5fc6984558bd455a33e275f7060d42c93c21720
The shims that this rule tests for no longer exist.
MozReview-Commit-ID: DMgP7Hczavc
--HG--
extra : rebase_source : 765ddd5c62c9449c07ed050e44d86a3bd5c0ae64
extra : amend_source : 627a7694ac07182200f876901ded7a34721cd228
The overlay was responsible for script loading and defining three elements
(bhTooltip, placesCommands, placesContext). In the majority of places where
the overlay was included only part of it was used. To remove the overlay, the
elements were each split into include files and moved into where they
were used. For the scripts, a JS file was added that defines all the lazy
modules and then this script, globalOverlay.js and utilityOverlay.js were
inlined to everywhere that would have included them from the overlay.
MozReview-Commit-ID: 8T5D46oYWLn
--HG--
rename : browser/components/places/content/placesOverlay.xul => browser/components/places/content/placesCommands.inc.xul
rename : browser/components/places/content/placesOverlay.xul => browser/components/places/content/placesContextMenu.inc.xul
extra : rebase_source : c1071af4ea264a95183cbc65caae98feb23d58e5
When background tabs crash, they were being replaced by about:blank tab
hosted in parent process.
Now that there is a mechanism for lazily creating browsers, discarding the
crashed background browser until they are selected is a cheaper operation
(compared to creating about:blank).
Certain test cases were also updated to take into account the new scenario.
--HG--
extra : rebase_source : ab2c6c7b2faf5710ebfc52259632fbcd6d67b5fa
extra : amend_source : 0e15fb0f4818273daa3438d4e297f42558c1fc55
Note that this patch also replaces legacy VK_* with KEY_*, and replaces
synthesizeKey() for inputting some characters with sendString() because
it's better and clearer what it does and it sets shiftKey state properly.
MozReview-Commit-ID: De4enbjux3T
--HG--
extra : rebase_source : 2296b84bff8e22f01eeb48cd8614fac5db11136a
Now, callers of EventUtils.synthesizeKey() don't need to specify
KeyboardEvent.code value anymore if they assume that active keyboard layout
is US keyboard layout.
Note that this patch changes the meaning of only test_bug551434.html.
Some callers in it don't match the key value and code value but that looks
like that they don't checking such odd keyboard events. So, they must be
bug of the test.
MozReview-Commit-ID: Itxo7yZ9rkK
--HG--
extra : rebase_source : 856ef3715c924ca16e993ea57d92d1243b5cc6be
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
nsIDOMWindowUtils.sendKeyEvent() can dispatch any keyboard events, i.e.,
may dispatch different key events from actual Gecko's behavior. Instead,
they should use nsITextInputProcessor directly or synthesizeKey() of
EventUtils which wraps nsITextInputProcessor.
MozReview-Commit-ID: EDWqXy1OxJp
--HG--
extra : rebase_source : 158c6f3d1611646540133297e4c8352e0b85ab79
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
When background tabs crash, they were being replaced by about:blank tab
hosted in parent process.
Now that there is a mechanism for lazily creating browsers, discarding the
crashed background browser until they are selected is a cheaper operation
(compared to creating about:blank).
Certain test cases were also updated to take into account the new scenario.
MozReview-Commit-ID: AaOivEoTOvU
--HG--
extra : rebase_source : 407ec73ac5ce39906f2e3e0c6f99c8313b544dad
The property values are already normalized according to the spec.
MozReview-Commit-ID: DbKZf9KXCji
--HG--
extra : rebase_source : 13b94e29dc0a32185d9fcb60e503988a722ea60a
In this test, it was possible for browser2 to finish loading _before_ the
BrowserTestUtils.browserLoaded function we were awaiting on for browser1 had
yielded back to the test, meaning that by the time we got to run
BrowserTestUtils.browserLoaded(browser2), the browser was already done loading,
and browserLoaded would be waiting for a page load that would never occur.
MozReview-Commit-ID: EagrRrAAdJP
--HG--
extra : rebase_source : 7732395344b0a0f0c584045ea975c0b178efd170
With the removal of the old addonHistograms, all histograms are now registered.
So removing registered(Keyed)Histograms should be straightforward?
Unfortunately not, as this was how we filtered data based on dataset
(opt-in/opt-out), so a little more fiddling was needed to get C++ to only
serialize dataset-appropriate data (instead of post-facto filtering it in JS).
MozReview-Commit-ID: HDplhmzmzJl
--HG--
extra : rebase_source : 9c38c97e39e3c4fb192288d751505e1f0f2a2c6d
Previously gecko would drop all subframe history entries on reloading if there
exists one or more dynamic subframes. With bug 1326251 and this bug, now that
dynamic frame entries are bound to bfcache (so they're still dropped on
reloading) but static entries are always kept in normal reloads.
Force reload would still drop all subframes regardless they're static or
dynamic, so for this test case I think we should just use a force reload.
MozReview-Commit-ID: 2mZZa59RMHB
--HG--
extra : rebase_source : 188b27f9566ce0652ca92c7765761ad3fd0b8c99
The reasoning behind this is that with this change, removing a non-dynamic
docshell from the document dynamically shouldn't affect the indexes which we use
for both recording and restoring data in child docshells.
MozReview-Commit-ID: JIK8GBSWDEF
* * *
fixup
From c2cb8e33211348c36b1ce18bb62e6465fa46d3ae Mon Sep 17 00:00:00 2001
These tests use BrowserTestUtils.crashBrowser() and fail with ASan enabled.
MozReview-Commit-ID: CpkldaKouzD
--HG--
extra : rebase_source : 02c4c0c13e7ab3ba144b2922b0cc54913daa6ab9
Some tests were using "secret" APIs to get at telemetry knowledge from various
processes in various ways. Adjust them so that they work with the new ways of
doing things.
MozReview-Commit-ID: 2iBL00HVGyg
Some tests were using "secret" APIs to get at telemetry knowledge from various
processes in various ways. Adjust them so that they work with the new ways of
doing things.
MozReview-Commit-ID: 2iBL00HVGyg
The reasoning behind this is that with this change, removing a non-dynamic
docshell from the document dynamically shouldn't affect the indexes which we use
for both recording and restoring data in child docshells.
MozReview-Commit-ID: JIK8GBSWDEF
This also reworks an async function to read more linearly.
MozReview-Commit-ID: JPzRlCNWY65
--HG--
extra : rebase_source : 55cbcfca6026f9700daa0061ba38615be5670b90
If the tab was resumed before, it could start playing any autoplay media without user's
permission after session restore.
MozReview-Commit-ID: C3DHIIsLtJA
--HG--
extra : rebase_source : d415d26d9ddcc9cb2949eb3215aee74f4c85912c
The browser-chrome test suite now detects and reports unhandled rejections of native Promises, in addition to those created by Promise.jsm. The whitelisting mechanism is updated to use primarily the PromiseTestUtils.expectUncaughtRejection function. Tests will fail if a rejection that is not whitelisted occurs, or if a whitelisted rejection does not occur anymore.
MozReview-Commit-ID: 1beGB5GG8Ty
--HG--
extra : rebase_source : b6573f8e2001f91d0e5a50f6376b191459549e94
extra : intermediate-source : 0411e687044ecc7b56684196238e6e6e68a9d685
extra : source : 8d53be05afc59519c5ce8cfae96d284a972fda71
We currently show a full URL as the initial tab title (e.g. "https://www.mozilla.org/en-US/") until the page loads and we know the actual page title. When loading multiple tabs, such as during session restore, many tabs will have the same undifferentiated tab title prefix like "https://www....". Since the URL scheme and "www." subdomain are not meaningful to users, just show the URL's hostname without any "www." prefix (e.g. "mozilla.org").
Other browsers' initial tab titles for comparison:
* Firefox 54 uses "Connecting...".
* IE11 uses the same "hostname without www" placeholder as this changeset.
* Edge uses "Blank page".
* Chrome uses "Loading..." on Windows and "Untitled" on Mac.
* Safari uses "Untitled".
MozReview-Commit-ID: JxLxvBjpIBh
--HG--
extra : rebase_source : b57987e2d61b2798b4e85045ac03a0a33965d138
This test case documents the current behavior of about: pages's initial tab titles. The fix for bug 1364127 caused about: pages' initial tab titles to show their about: URIs until their actual page titles are known, e.g. "about:addons" -> "Add-ons Manager". This is bug 1371896. Previously, about: pages' initial tab titles were blank until the page title was known.
This test case uses the about:robots page because its title is not localized, which makes testing easier.
MozReview-Commit-ID: JGaRciaZUEC
--HG--
extra : rebase_source : a55a6d438774462e8862f9c3890d32f9dfa6f511
The browser-chrome test suite now detects and reports unhandled rejections of native Promises, in addition to those created by Promise.jsm. The whitelisting mechanism is updated to use primarily the PromiseTestUtils.expectUncaughtRejection function. Tests will fail if a rejection that is not whitelisted occurs, or if a whitelisted rejection does not occur anymore.
MozReview-Commit-ID: 1beGB5GG8Ty
--HG--
extra : rebase_source : 64395c5fdf25deebd60dfbf2cf5df3cbf7ca8abb
extra : amend_source : 0a3f13419c050662680f2bd110d724b3bf991732
extra : source : 8d53be05afc59519c5ce8cfae96d284a972fda71
The browser-chrome test suite now detects and reports unhandled rejections of native Promises, in addition to those created by Promise.jsm. The whitelisting mechanism is updated to use primarily the PromiseTestUtils.expectUncaughtRejection function. Tests will fail if a rejection that is not whitelisted occurs, or if a whitelisted rejection does not occur anymore.
MozReview-Commit-ID: 1beGB5GG8Ty
--HG--
extra : rebase_source : 59e5b84cb431f3ca28287d30a3da8fbea1363ec5
DevTools are moving out of mozilla central, and since this test is relying on scratchpad
being available, it would probably make sense to move it to the scratchpad test suite
which will still be run in the new devtools continuous integration setup.
MozReview-Commit-ID: 19x6Ccp85ND
--HG--
rename : browser/components/sessionstore/test/browser_644409-scratchpads.js => devtools/client/scratchpad/test/browser_scratchpad_sessions.js
extra : rebase_source : bf564025199748b43ef56333f5c5626b266be1ca
If the tab was resumed before, it could start playing any autoplay media without user's
permission after session restore.
MozReview-Commit-ID: C3DHIIsLtJA
--HG--
extra : rebase_source : 9517525aa242bff3150a902070544cf64c5ba6c1
Robot favicon (image/png) is currently only used in about:robots
(browser/base/content/aboutRobots.xhtml), but we intend to re-use this
resource for indicating that the browser is under remote (robot) control.
MozReview-Commit-ID: 4eTNbAITPQx
--HG--
extra : rebase_source : 765e4e2d7abe95ecc48b6a55582bde73fb689d5e
This patch replaces FX_SESSION_RESTORE_CONTENT_COLLECT_DATA_LONGEST_OP_MS with
a more fine-grained data collection via a keyed histogram so that we can
determine which type of data collection we spend a lot of time on.
Additionally, it abandons sending telemetry data from the content to the parent
via custom messages and instead uses the Telemetry service directly. Thus it
also gets rid of a bug that currently overrides measurements for the same
histogram done quickly in succession
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
--HG--
extra : rebase_source : 8939e453c2277caa4a90123ae09bb542aaa421ed
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
--HG--
extra : rebase_source : 82a6934d90bbbbd25f91b7b06bf4f9354e38865a
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.
--HG--
extra : histedit_source : b7ea6a6fbfee2f3a2bddeaa69b6446d7544c2585
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.
This changeset changes tests using ForgetAboutSite.removeDataFromDomain
to yield on it, since now it is a Task
MozReview-Commit-ID: 72OEYoO1avd
--HG--
extra : rebase_source : 9ea8cc06493c3e965d260dc9377461ff29fe572a
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
--HG--
extra : rebase_source : 20bdc1f116b27f7386a9b7d1cdc0ad383b21b99c
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
--HG--
extra : rebase_source : 61d2aa91bf9474af3d72a5dea41b25dca442c1b7
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
--HG--
extra : rebase_source : ea872b615ebe3d8639b214bfafc5e358ba6e65fd
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
--HG--
extra : rebase_source : 5e1dbbaf0e1fb641bd43f821980ab5dff7272b04
This patch is generated by the following sed script:
find . ! -wholename '*/.hg*' -type f \( -iname '*.html' -o -iname '*.xhtml' -o -iname '*.xul' -o -iname '*.js' \) -exec sed -i -e 's/\(\(text\|application\)\/javascript\);version=1.[0-9]/\1/g' {} \;
MozReview-Commit-ID: AzhtdwJwVNg
--HG--
extra : rebase_source : e8f90249454c0779d926f87777f457352961748d
