Currently the ZoomToRect function is only ever called on Android, on the
UI process main thread, which is neither the controller nor the sampler
thread. Instead of allowing "random" threads to run inside APZ, we
ensure that callers run it on the controller thread.
Without this patch, UpdateZoomConstraints can get called on:
a) the compositor/sampler thread (over PAPZCTreeManager)
b) the controller thread which is also the UI process main thread (on
desktop platforms without a GPU process)
c) the UI process main thread when it's *not* the controller thread (on
Android).
Instead of having to reason about all these scenarios separately, we can
try to unify them a little bit by ensuring the function contents always
run on the sampler thread, which is the thread that seems to make the
most sense for it.
These two functions (UpdateWheelTransaction and ProcessUnhandledEvent)
are only ever called on the concrete APZCTreeManager when the APZ code
is living in the GPU process. This is because the calls are made by the
IAPZCTreeManager implementation which lives in the UI process, and
remoted over PAPZCTreeManager. So the assertion is safe, and will help
us guard against inadvertent breakage when we try making a different
thread the controller thread in the GPU process.
In addition, the WillHandleInput function can be called in the GPU
process on the compositor thread, but we will allow it to be called on
the main thread as well. In that case we need to ensure we don't try
running EventStateManager pref-reading code in the GPU process, and
instead preserve the current behaviour of just returning true.
This function is never actually called over IPDL. It is called directly
on the concrete APZCTreeManager instance by the
AndroidDynamicToolbarAnimator code, both of which live in the
compositor. So we don't need to expose this method on IAPZCTreeManager
or over PAPZCTreeManager.
Since we can have multiple browser windows on multiple different
displays with different DPIs, it doesn't make sense to have a single
static DPI value shared across all APZCTreeManagers. Instead, each
APZCTM should store its own DPI value for the display the window is on.
Since the DPI is only ever read from the controller thread, we can make
it bound to that thread, and update the setter code to also set it on
that thread.
As with the previous patch, the change in APZCTreeManagerParent is a
no-op but allows making some other thread in the GPU process the controller
thread. And the change in nsBaseWidget is a no-op everywhere except
Android.
- The change in APZCTreeManagerParent is functionally a no-op because it
only ever runs in the GPU process on the controller thread. But it
allows moving the controller thread to some other thread.
- The change in nsBaseWidget is a no-op for desktop platforms, because
in the UI process the main thread is the controller thread. But on
Android it moves the call from the main thread to the Java UI thread.
Before bug 1413181, HTMLEditRules::SplitMailCites() receives left node of
split node with |leftCite| from SplitNodeDeep(). However, the out argument
was removed by the bug and now, it can be retrieved with
SplitNodeResult::GetPreviousNode(). Its result is used for creating <br>
element etc, but not set to |leftCite| but HTMLEditRules::SplitMailCites()
still checks if |leftCite| is empty to remove it from the DOM tree.
So, now, both |leftCite| and |rightCite| are not necessary and
HTMLEditRules::SplitMailCites() should use |previousNodeOfSplitPoint|
instead of |leftCite|.
MozReview-Commit-ID: 408MJt6X1IV
--HG--
extra : rebase_source : fa6095ccc972d33afe8deb0f124adffea7371f4e
To correctly apply pixel snapping during display list construction we would need to snap each tile of a repeated gradient individually. It's preferrable to do this in WebRender rather than decompose gradients into many display items.
Now we're loading the sizemode attribute earlier, doing this on load stops
working.
MozReview-Commit-ID: ToiJiYrvFw
--HG--
extra : rebase_source : 48ad80e5535ecc5f7c8c8297f417f797deddc017
extra : source : 80194b5bf0e7bbcccf727d2fec140e747ebd0949
extra : histedit_source : 2b7755fece2a564fc806369280559c8829d3d486
To avoid hacking around the empty window, and handle the activation issue seen
on Windows / OSX.
MozReview-Commit-ID: oK3T8FKd5n
--HG--
extra : rebase_source : 4d1ed1bae673b3b0e533d7c66303a3cf995fda8b
extra : source : 461021b4bf3ab189babba096584682b2469ce9df
extra : histedit_source : eaa97d93bb4e100e1410471b19585ac125bd828d
This gives the chance to code that relies on setting the XUL window attributes
to run before we actually size the window.
This should prevent the resizing on OSX and fix some other untested stuff that
the first commit probably broke...
MozReview-Commit-ID: DhCWgmCppek
--HG--
extra : rebase_source : 253bea4c4e90727c0e8cce4726bf7a695ca26d9d
extra : source : 4d6f855ea529f6043b3ca886f53901e16a3d6405
extra : histedit_source : b0aa76063dca7a85e43b3bf670aab8f185a57915%2C760885a660c4fd92e7ae777614ad3cdc84dc9b31
The only subtle thing is the mCenterAfterLoad stuff, which is gated after a
mChromeLoaded.
Other than that it follows the same pattern as bug 345560.
MozReview-Commit-ID: 8qDiA2yn9DB
--HG--
extra : rebase_source : 8ad309e3f449cea1536bfbff8e8b1585fefbc186
extra : source : f582644f846cee16b554d694d24b4eb8ca3c5106
This policy disables the safe-mode UI entry points. In addition, only on Windows when using GPO, it also disables entering Safe Mode by holding down the Shift Key
When we swap <browser> frameloaders, the message managers on the parent side
also change. And since a frameloader swap is usually followed by the original
<browser> and its message manager being destroyed, this leads us to think the
message manager has disconnected earlier than it actually does.
MozReview-Commit-ID: LC9aaoynWzH
--HG--
extra : rebase_source : 7fdcd78d12bad8898a6219ee799f64e15427e189
We only use it for properties that return pixels anyway, so we can use it
without much problem.
This also fixes bug 1428974.
MozReview-Commit-ID: 5BbVOUdQT7o