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
Michael Layzell