The machinery for suppressing the displayport during live resizes
was using the Observer service. However, in the case of multiple
browser windows, this meant that all the open browser windows would
have their displayport suppressed if *any* of the browser windows
was being resized. This was mostly ok, as the displayport suppression
would be turned off once the resize ended. However, the code to
kick off a repaint with the unsuppressed displayport would only get
triggered on one of the windows (whichever happened to process the
unsuppress message last).
This patch stops using the Observer service for the implementation
machinery, and instead locates the active TabParent of the relevant
nsWindow, and invokes the displayport suppression directly on that.
This fixes the repainting bug and also avoids unnecessarily
broadcasting the suppression/unsuppression notification to windows
that don't neccessarily need it.
MozReview-Commit-ID: LBHOgOW9KUp
There can be cases where a non top level document currently has no parent
document, for example when a child doc has been unbound from its parent but
not yet reattached to a new outer doc.
This patch fixes:
* some long lines
* some odd indent
* wrapping one line blocks with {}
* removing B2G specific block
in event handlers in TabChild, TabParent and PuppetWidget.
MozReview-Commit-ID: 6xMsNEDA5nv
When TabChild recieves the Destroy message from its parent the doc accessibles
for that tab are shut down. However if the Shutdown message sent by
DocAccessible::Shutdown() isn't recieved before the child process handles the
runnable that sends __delete__ to the tab parent actor the parent can send a
message to the already shut down doc accessible child actor.
When TabChild recieves the Destroy message from its parent the doc accessibles
for that tab are shut down. However if the Shutdown message sent by
DocAccessible::Shutdown() isn't recieved before the child process handles the
runnable that sends __delete__ to the tab parent actor the parent can send a
message to the already shut down doc accessible child actor.
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 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.
We will use the new type for the generated IPDL message handler
prototype to make sure correct error handling method is called.
MozReview-Commit-ID: AzVbApxFGZ0
