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
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
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.
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).
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
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
Returning in onBrowserCrashed if the browser isn't remote breaks various tests, so I simply removed this seemingly bogus check.
MozReview-Commit-ID: IoHhzdc2p7Y