On B2G, the primary frame for tab content was not giving the correct process offset so we revert back to the mechanism we used to have in nsSubdocumentFrame.
Change the PuppetWidget from defining screen coordinates from tab-content-relative to being based on actual screen geometry. PuppetWidgets can have position. In the parent process, the widget has a position and a separate client position (that includes OS window chrome... on Linux and Windows as others have no chrome). In the child process, the widget (non-origin) position, whose calculation compensates for the OS window decoration.
TabParents now register for the MozUpdateWindowPos event on the chrome TopWindowRoot. When the window is moved, the OS widget calls WindowMoved on its listener (the nsWebShellWindow), which sends a MozUpdateWindowPos event.
PuppetWidget::WidgetToScreenOffset now reports proper widget screen location. Previously, in the content process, all widgets were defined to be located at the screen origin. This also repairs mac e10s OOP plugin coordinate calculations that would be broken by this change.
Should required data get evicted between the time we checked for availability
and the time we started seeking, it would have caused the seek to fail. Instead
cancel current seek and go back waiting for more data.
Installing a Webapp is an asynchronous job, and there is a pocket of time
between when web content requests to install an app and before the browser
displays an installation prompt that the outer window of the content can
browse away. This pocket of time is typically used by XHR to request the
web app resources and verify their contents.
This pocket of time is, essentially, bug 771294, and is a bit of a security
problem.
This problem was originally patched over on Desktop by checking in the parent
process that the outer window was still at the same URI as it had been when it
made the request. I'm not entirely sure if Android / B2G made similar checks.
With separated content processes, however, the browser front-end can no longer
performantly check to ensure that the outer window is at the same URI.
We solve this problem by sending up a message in the content process when
the location of an outer window making use of navigator.mozApps changes.
We hold a Map of "actions" mapping to in-flight installs mapped by the
outer window ID of the requesting content. When we notice a location
change, we mark those actions as cancelled. When the XHR returns, we have
it check the state of its actions, and if they're cancelled, it aborts
further action.
Normally, this wouldn't be necessary, since any XHR initiated by the
content window would be cancelled once the location changed, but in
this case, the XHR is occurring in Webapps.jsm, and is not influenced
by the outer window of the content.
--HG--
extra : rebase_source : 5f95002a21c96c5cbf3dca8ca265400448251b43
