This change has a couple of tests but they are for scrollable/non-scrollable
contents, they are not for non-scrollable contents but covered by the dynamic
toolbar cases, e.g. 100vh body element. Those cases will be introduced in the
subsequent change.
Differential Revision: https://phabricator.services.mozilla.com/D93915
Also add AsyncPanZoomController::CanScrollDownwardsWithDynamicToolbar to tell
whether the root APZC is scrollable or there is room covered by the dynamic
toolbar so that we can tell GeckoView to move the dynamic toolbar in such cases.
Differential Revision: https://phabricator.services.mozilla.com/D93914
This also adds a test. The velocities computed in the test are the following:
SimpleVelocityTracker: 0.65 with full data, 0.467 with partial data
AndroidVelocityTracker: 1.225 with full data, 0.833 with partial data
Differential Revision: https://phabricator.services.mozilla.com/D95651
If there is a scrollframe that is inactive but also visibility:hidden, then
we shouldn't create a hit test info for it, because APZ will consider it as
being visible. In the non-fission case this doesn't matter much but in the
fission case the input event could end up getting sent to the wrong process if
the hidden inactive scrollframe is sitting on top of an OOP iframe.
Differential Revision: https://phabricator.services.mozilla.com/D95767
With this patch, the system font seems to work OK again on 10.15 when building Firefox with SDK10.15,
provided webrender is *disabled*. We no longer trigger the Core Text error messages from InitSystemFontNames(),
and the proper system font is used.
(With webrender, we get garbage because it fails to instantiate the system font and renders "random" Times
glyphs instead.)
Differential Revision: https://phabricator.services.mozilla.com/D95453
Our fract offset for the tiles should be a simple mapping of the snapped
device position back to picture space. If no snapping is required, then
the position will be precisely the origin. When using this value to
decide if the position has changed for glyph subpixel offset purposes,
we must consider it in device space, since picture to device space can
be effectively arbitrary.
We update the stored fract offset at which a tile was rendered whenever
we invalidate the whole tile, not just when we detect the fract offset
has changed by a notable amount. This should reduce spurious
invalidations since the tile was actually rendered at a different offset
that we had recorded prior to this patch.
Differential Revision: https://phabricator.services.mozilla.com/D91156
We were (correctly) negating the velocity in ComputeVelocity, but not in
AddPosition, so the velocity was upside down during the pan and then flipped its
sign at the end of the pan.
Differential Revision: https://phabricator.services.mozilla.com/D95253
On macOS, the pan end events usually don't come with a displacement, so the call
to OnPan is unnecessary.
This change fixes the test APZCSnappingOnMomentumTester.Snap_On_Momentum when
the Android velocity tracker is used. The test was failing in the following way:
The test executes a pan gesture where the pan end event has a zero delta.
The pan end event is dispatched after a delay after the last delta-ful pan.
Calling OnPan for the zero-delta event at the end added an additional data point
to the velocity tracker's history, making it look like the pan had come to an
abrupt stop.
This abrupt stop distorts the quadratic polynomial which the Android velocity
tracker fits to the data points, causing the tracker to predicts a reversal of
the velocity.
This reversal causes the scroll snap to be initiated in the wrong direction.
We snap upwards instead of downwards, and the test fails.
This patch fixes the failure because the velocity tracker no longer sees an
abrupt stop, so it no longer predicts a reversal of the pan direction.
For the regular velocity tracker, we add another delta-ful pan event to the test,
to have enough deltas to compute a velocity from. This test will fail if a zero
velocity is computed, due to a problem described in bug 1674308.
Differential Revision: https://phabricator.services.mozilla.com/D95251
This makes the following tests pass on Android:
APZCFlingStopTester.FlingStop
APZCFlingStopTester.FlingStopSlowListener
APZCFlingStopTester.FlingStopPreventDefault
APZScrollHandoffTester.SimultaneousFlings
APZScrollHandoffTester.ScrollgrabFling
APZScrollHandoffTester.ScrollgrabFlingAcceleration1
APZScrollHandoffTester.ImmediateHandoffDisallowed_Fling
It causes the following test to start failing on non-Android:
APZScrollHandoffTester.ScrollgrabFlingAcceleration2
That's because the reduced time between the pan events causes a higher scroll
speed, so the fling goes faster and farther, and hits overscroll. This will be
fixed in a later patch in this series.
Differential Revision: https://phabricator.services.mozilla.com/D95247
This only really makes a difference when the pref is set to zero: Now we will no
longer attempt to kick off no-op flings. Many of the APZ gtests are manually
setting the pref to zero, and were unintentionally kicking off no-op flings.
As a result, they were crashing on an assertion in APZFlingPhysics which checks
that flings always start with a non-zero velocity.
When the pref is set to a non-zero value, which is the case for our users, it
doesn't really make a difference whether we check > or >=, because users are
very unlikely to hit the "==" case. So this patch shouldn't affect the user
experience.
As a result of this change, the following test starts passing on Android:
APZCFlingStopTester.FlingStopTap
There are a lot more tests that were hitting this assertion, but those are still
failing for other reasons.
On non-Android, this change causes the following test to fail:
APZCPinchGestureDetectorTester.Panning_TwoFingerFling_ZoomDisabled
That's because the regular velocity tracker determines a velocity of zero, and
the test checks that a fling is started. This test will be fixed in an upcoming
patch in this series.
Differential Revision: https://phabricator.services.mozilla.com/D95246
This removes some of the complexity in the renderer associated with
drawing multiple document layers in a single render. It retains
the rest of the document API, which will be used to implement the
functionality in bug #1654938.
Differential Revision: https://phabricator.services.mozilla.com/D95478
If there's a device error trying to read some of the data from a font, it's better to catch the exception
and leave that individual font unusable (without names or character map) than to crash the whole process.
Differential Revision: https://phabricator.services.mozilla.com/D95146
Span shaders can be defined in GLSL by defining a function named swgl_drawSpanRGBA8
(or R8 depending on output format). A set of extended SWGL intrinsics is defined in
swgl_ext.h that provides various optimized means for implementing these span shaders.
This replaces the older C++ include-file based draw_span functionality that was
unfinished and cumbersome to use with a more flexible mechanism that interacts better
with fragment shaders.
Differential Revision: https://phabricator.services.mozilla.com/D95109
Span shaders can be defined in GLSL by defining a function named swgl_drawSpanRGBA8
(or R8 depending on output format). A set of extended SWGL intrinsics is defined in
swgl_ext.h that provides various optimized means for implementing these span shaders.
This replaces the older C++ include-file based draw_span functionality that was
unfinished and cumbersome to use with a more flexible mechanism that interacts better
with fragment shaders.
Differential Revision: https://phabricator.services.mozilla.com/D95109
I spent a lot of effort trying to get this test to work when I originally landed it, as document in the comments on https://phabricator.services.mozilla.com/D92891
At the end of that I mistakenly concluded it magically started working because I forgot to set a pref when doing a try push.
The test is checking that a paint _doesn't_ happen. So you must go to great care to make sure a random paint doesn't happen. The test is stable enough on desktop but on mobile some other paints creep in. I tried to fix that but I had already spent a ton of time on it and it didn't seem fruitful. Having the test on all desktop platforms should be good enough.
Flipping apz.force_disable_desktop_zooming_scrollbars pref on android exposes this failure. (The test is testing a regression from flipping that pref on desktop).
Differential Revision: https://phabricator.services.mozilla.com/D95419