Re-introduces support for setting remote icons provided a loading principal is
passed. Removes some now defunkt code from sessionstore.
Differential Revision: https://phabricator.services.mozilla.com/D3123
--HG--
extra : rebase_source : f039f34d13aa43c52af880d8f59962f6450791be
extra : amend_source : e60b5d7fb22538728837d5196b866ecf2284bc64
Creating non-shared scopes for frame scripts is fairly expensive. After these
changes it's even more expensive. However, many frame scripts have no use for
the shared scopes at all. Run-once scripts which execute in closures, for
instance, make no use of them. And after bug 1472491, neither do most of our
default frame scripts.
MozReview-Commit-ID: 9PK7bYdQ0yh
--HG--
extra : rebase_source : db2516d2f00a75e233e1957649f2b62a9299b7cd
Before this change, we accessed the browser URL in the following ways:
- "chrome://browser/content/browser.xul"
- "chrome://browser/content/" (which redirects to chrome://browser/content/browser.xul)
- Services.prefs.getCharPref("browser.chromeURL") which returns "chrome://browser/content/"
- getBrowserURL() from utilityOverlay.js
MozReview-Commit-ID: I5vtRke1x9t
--HG--
extra : rebase_source : c525350a1954740873e85b045cbb14a8b43aa89d
Also changes the tooltip on the home button to be independent of the URLs
it opens, per dolske.
Some tests explicitly set browser.startup.homepage, but only through
SpecialPowers.putPrefEnv. That's a good compromise, given the extra
functionality there.
MozReview-Commit-ID: FPLxzi3jQAP
--HG--
extra : rebase_source : c2b014f2fb1c78ce04859344bd1803ef48d5d68d
If discard is used immediately after creating a tab, restoring the tab
resulted in an unusable tab. This was due to the sessionstate not being
ready. This adds enough sessionstate to restore when this occurs.
MozReview-Commit-ID: 6PIc71BS8VU
--HG--
extra : rebase_source : 1bb9627eee561e9bf924e9eb2a34a5071cae3742
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
Since we want to start collecting all form data through mapFrameTree on Fennec,
too, we need to change our filtering strategy for form data.
We can no longer bail out directly during the data collection loop and instead
have to filter the data after having collected all of it.
The easiest way to do that is to start using PrivacyFilter.filterFormData() on
Android as well.
MozReview-Commit-ID: GBos4Zn3l2U
--HG--
rename : browser/components/sessionstore/PrivacyFilter.jsm => toolkit/modules/sessionstore/PrivacyFilter.jsm
extra : rebase_source : 1c5dfce28716c82e3a237f6d559449cb904ae13a
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
Relying on this._browserSetState was incorrect as that is only set via tests. It needs to be always true so session restore works in the right order.
The lazy restore is fine in the test, and avoids the about:blank intermittent (or at least makes it much much harder to reproduce on my linux vm).
This patch implements the preference "browser.tabs.insertAfterCurrent" which,
when set to true, will cause all tabs (related and unrelated) to be opened next
to the current tab.
It also implements the browserSettings API "newTabPosition", which allows
extensions to control both "browser.tabs.insertRelatedAfterCurrent", and
"browser.tabs.insertAfterCurrent" via values for "afterCurrent",
"relatedAfterCurrent" and "atEnd".
The code for "browser.tabs.insertAfterCurrent" including the test for it is
mostly taken from a patch attached to bug 933532 written by Masayuki Nakano.
MozReview-Commit-ID: KQE7M2FGpc7
--HG--
extra : rebase_source : d2dd721a58e675fc1db88ab0c0b90bb62e283231
nsFrameLoader is on WebIDL bindings, so those QIs are no-ops anyway, unless the given object is no a frameloader to start with.
MozReview-Commit-ID: IPiW70H5NPc
Importing this object is unnecessary after the updates to the WebIDL console from Bug 1425574
and the follow-ups blocking Bug 1430810. There are still callers that access Console.jsm
to create custom ConsoleAPI objects, but those will be handled separately.
MozReview-Commit-ID: 9ojFxtkpPId
--HG--
extra : rebase_source : 971bf99f709b8d2afe300f3693665724f747aa5e
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
When in permanent private browsing mode, always return false
for isAutomaticRestoreEnabled. This ensures that there will
not be any confusion inside nsBrowserContentHandler.defaultArgs
as to whether a one time session restore will occur.
Also, for consistency and in case someone looks at the pref,
avoid setting browser.sessionstore.resume_session = true during
browser shutdown.
This bug occurred when staging was not used during the update
process. On Windows it always occurred because staging is not
used even when it should be (https://trac.torproject.org/18292).
