In bug 1147911, the concept of a remoteType was added to a xul:browser.
This was an attribute which would control the type of remote process was
intended to be used to load the page.
In order to swap two frameLoaders, it has always been necessary for them
to either both contain remote content, or both contain non-remote
content. This check is made in nsFrameLoader::SwapWithOtherLoader, by
checking `IsRemoteFrame() != aOther->IsRemoteFrame()`, and then
returning `NS_ERROR_NOT_IMPLEMENTED` if that was not the case.
In the follow-up bug 1317293, the check which is being removed here was
added to ensure that the remoteType of two frameLoaders which are being
swapped also matched. This was not a technical limitation, but rather
something which "seemed to make sense to do".
This bug removes that check as it is not a technical limitation and
causes problems in edge cases around Large-Allocation processes now that
the remoteType is being used to denote a Large-Allocation process.
Namely, it means that attempting to drag a Large-Allocation window into
a new window when at the Large-Allocation process cap will fail, due to
being unable to create a new Large-Allocation process in the new window
to swap with.
The new swapping of the attributes which is added below is done with the
intent that the `remoteType` attribute of the xul:browser element should
match the `remoteType` attribute of the frameLoader inside of it at all
times. As the swap can now occur between two different `remoteType`s,
this is necessary to keep that constraint.
MozReview-Commit-ID: BHFgjwRGrge
This changes the `relatedBrowser` property which held a <xul:browser> to the
more explicit `sameProcessAsFrameLoader` which takes an nsIFrameLoader.
This clarifies the purpose of the property and also (by switching to the frame
loader) makes it easier to set in some contexts.
MozReview-Commit-ID: LnEvSP8zkto
--HG--
extra : rebase_source : f9f4c07995ef39f1ccd5042e9ae3df37879423b6
With GroupedSHistory, history navigations may now require the browser to
change which frameloader is stored internally from within Core. This
patch adds a mechanism to allow for chrome code to respond to these
changes and both delay the change, or respond once the change is
performed.
Delaying the change is accomplished through the BrowserWillChangeProcess
event, which is fired when it is determined that a process change will
happen for the given browser, but the change has not occured yet. During
this time the nsIFrameLoader::AddProcessChangeBlockingPromise method may
be called on the target browser's frameloader. Any promises passed to
this method will be waited on, and the process change will not occur
until they have all been fulfiled.
Once that has occured, the process change occurs, and the
BrowserChangedProcess event is fired.
This is useful for chrome code which needs to flush state from the
original process before the change, and then which needs to connect
state in the new process with state in the chrome process.
MozReview-Commit-ID: C0Xn6pfruB2
This adds a single flag, SWAP_KEEP_PERMANENT_KEY, which tells the
browser that when it performs the swap, the permanent key should stick
with the browser, rather than following the frameLoader.
This patch also adds the implementation of tabbrowser.swapBrowsers,
which was previously absent, despite being referenced.
MozReview-Commit-ID: CLwJYzpY8Pp
This patch removes support for mozapp iframes, leaving support for
mozbrowser iframes intact. Some of the code has been rewritten in order
to phrase things in terms of mozbrowser only, as opposed to mozbrowser
or app. In some places, code that was only useful with apps has been
completely removed, so that the APIs consumed can also be removed. In
some places where the notion of appId was bleeding out of this API, now
we use NO_APP_ID. Other notions of appId which were restricted to this
API have been removed.
This patch removes support for mozapp iframes, leaving support for
mozbrowser iframes intact. Some of the code has been rewritten in order
to phrase things in terms of mozbrowser only, as opposed to mozbrowser
or app. In some places, code that was only useful with apps has been
completely removed, so that the APIs consumed can also be removed. In
some places where the notion of appId was bleeding out of this API, now
we use NO_APP_ID. Other notions of appId which were restricted to this
API have been removed.
Since the apps service always returns error codes now, there's no need to ask if
any apps are installed prior to allowing non-isolated mozbrowser frames. This
change prevents an error from being logged due to the thrown exception from the
apps service.
MozReview-Commit-ID: DbD960jo0wB
--HG--
extra : rebase_source : 4b7c28f7c9a41722c47fce04e21fd8fc4de7fed9
When swapping content from <iframe mozbrowser> to <xul:browser>, we now stop the
frame scripts that implement the content side of the browser API since they are
no longer needed and can cause issues if they remain active.
MozReview-Commit-ID: JrecxA4MI93
--HG--
extra : rebase_source : cc68b975c7d82035410a647ff66eab130055ed04
Yoshi Huang
Andrea Marchesini
Mats Palmgren
Michael Layzell
Benjamin Smedberg
J. Ryan Stinnett
Bob Owen
Kartikaya Gupta
Gijs Kruitbosch
Cameron McCormack
Samael Wang
Carsten "Tomcat" Book
Boris Zbarsky
Kris Maglione
Ehsan Akhgari
Wes Kocher
Valentin Gosu
Phil Ringnalda
Iris Hsiao
Bill McCloskey