SetTestSampleTime is called from tests via the advanceTimeAndRefresh API
on DOMWindowUtils, and the expectation is that after it is done, the
time has been advanced and a composite has happened. So we need to
ensure that is the case with WebRender as well. This fixes the issue I
was seeing with test_group_hittest.html and makes it pass.
MozReview-Commit-ID: 86l9mTTwD2v
--HG--
extra : rebase_source : d2921fb0f9b09f4366fb516e4a6254a7f13f3e4e
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
This corresponds to the treatment of such layers in AsyncCompositionManager
added in bug 1168263.
MozReview-Commit-ID: 34IKk5TH9vV
--HG--
extra : rebase_source : 441d173e486b9be6557916219a849b2f9425d55b
Scheduling a composition sets the mNeedsComposite flag in the compositor
scheduler, so that advancing the time via advanceTimeAndRefresh doesn't
do an early-exit.
MozReview-Commit-ID: KvldsCCY0SD
--HG--
extra : rebase_source : e661e430c36553ce95d7798b4bc95ffaab48ab90
CompositorBridgeParent::GetIndirectShadowTree is meant to be a
compositor thread only method. This however was not enforced with an
assert and over time we began using it on the main thread for simple
accesses. These accesses should generally be safe on the main thread,
depending on the individual access, but not outside the lock
GetIndirectShadowTree holds. As such, a safer variant is provided to
execute a lambda inside the lock context, and the unsafe variant will
assert it is indeed in the compositor thread context.
The GTests don't have a way of setting up the relevant state in WebRender
for the hit test to succeed.
MozReview-Commit-ID: IyjK349MN5u
--HG--
extra : rebase_source : 9bc662601b6424fc956107a04f03e7d979bb1d1c
Mechanism for restricting pinch zooming when gesture is a two
finger pan. If the pinch span is below a given threshold and the
scroll distance above a given threshold then the zoom level is
maintained to allow for smooth panning with two fingers.
MozReview-Commit-ID: 62Fv0WeplOo
--HG--
extra : rebase_source : 71d7da4c4b4cc3a5adde13ad1a7c1fbf49856c35
This patch requires that each instance of IPC's RunnableFunction is
passed in a name, like the non-IPC RunnableFunction.
MozReview-Commit-ID: Atu1W3Rl66S
--HG--
extra : rebase_source : f932d7597a26a3f0c4246b3a95df638860d3d32d
This drops the code that compares the WR and Gecko hit-test results when
WR is enabled, because the "baseline" Gecko hit-test result is not
correct enough to provide a useful comparison. Instead flipping the pref
now just enables the WR hit-test code; we will rely on automated testing
to check for correctness.
MozReview-Commit-ID: 8IFtk0p2NvE
--HG--
extra : rebase_source : 6402a87f3345ca3b82220e42185c9f8776475cdd
This allows us to fire MozMouseHittest events from tests and then read
the hittest result from the compositor APZTestData. The MozMouseHittest
event was chosen in particular because the existing uses of it are
similar in nature - it is a dummy event that is used to determine what
elements a particular coordinate targets. It is also an event that is
never generated by the OS and so using this event gives us more control
over what ends up in the APZTestData.
MozReview-Commit-ID: KHjIX7EpK2A
--HG--
extra : rebase_source : f7d7d729c1935eefd49ed06d8644ff9ef537f2e1
Passing FlingHandoffState around as an in-out parameter was making
the next change (respecting overscroll-behavior) messy.
MozReview-Commit-ID: 4wuoll20Jt7