Testing Wanted: APZ Scrollbar dragging

[Benoit Girard]

Currently APZ does not cause scrollbar initiated scrolling to be async.
I've been working in fixing this and I'd like some help testing it out
before enabling it on Nightly. If you're interested please flip
'apz.drag.enabled' to true and restart. If you find any issue please make
it block https://bugzilla.mozilla.org/show_bug.cgi?id=1211610.

I've got a test page here to confirm that it's turned on properly:
http://people.mozilla.org/~bgirard/scroll_no_paint.html

Scrolling on this page is slow in FF because it hits a performance bugs in
layer construction code. However with APZ the scrolling is smooth and a bit
checkerboard-y instead. If you have 'layers.acceleration.draw-fps' set you
should notice the left most FPS counter at 60 FPS while the middle counter
will be much lower. This is APZ handling the scroll.

Happy Testing,
Benoit

[Nicholas Alexander]

Benoit, (possibly kats),

On Wed, Feb 17, 2016 at 10:35 AM, Benoit Girard <bgi...@mozilla.com> wrote:

> Currently APZ does not cause scrollbar initiated scrolling to be async.
> I've been working in fixing this and I'd like some help testing it out
> before enabling it on Nightly. If you're interested please flip
> 'apz.drag.enabled' to true and restart. If you find any issue please make
> it block https://bugzilla.mozilla.org/show_bug.cgi?id=1211610.
>

Does this apply to Fennec? Do you also want testing on Fennec? A
cross-post to mobile-firefox-dev might be in order.

Nick

[Benoit Girard]

This is mouse based. I don't believe we support mouses at all on mobile. I
also don't think we support touch interacting with the scroll thumb on
mobile. So unless there's an unusual device configuration I don't think
this applies to mobile.

On Wed, Feb 17, 2016 at 4:34 PM, Nicholas Alexander <nalex...@mozilla.com>
wrote:

[Ben Kelly]

This suggests it's possible to use a Bluetooth mouse with an Android device:

https://mobile.twitter.com/patrick_h_lauke/status/698898777562836992

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Jonas Sicking]

Hi Benoit,

There's two problems that I've seen related to scrolling, and so
possibly the result of APZ.

The most obvious one is that if the child process is busy doing
things, then the scrollable area seems "sticky". When you start
scrolling there's a noticeable delay before the page starts scrolling.

My guess is that we send some message to the child process when
scrolling is initiated and don't start scrolling until the child
process responds (possibly with some form of timeout)?

This isn't noticeable on the example page that you provided, possibly
because the child process is quite responsive before we start the
heavy painting operations.

The other problem, which is more serious, is that every now and then
the browser seems to get into a state where I can't use the trackpad
at all to do scrolling. The scroll bar is displayed, as is common when
using the trackpad to scroll, but no scrolling actually happens.

The only way I can scroll when the browser is in this state is to
hover the scrollbar and click below the scroll thumb, which enables
scrolling one page at a time.

The only way to get out of the state is by restarting the browser.

Sadly this happens very infrequently, so I haven't been able to create
steps to reproduce, nor seen any pattern in where it triggers.

/ Jonas

On Wed, Feb 17, 2016 at 10:35 AM, Benoit Girard <bgi...@mozilla.com> wrote:
> Currently APZ does not cause scrollbar initiated scrolling to be async.
> I've been working in fixing this and I'd like some help testing it out
> before enabling it on Nightly. If you're interested please flip
> 'apz.drag.enabled' to true and restart. If you find any issue please make
> it block https://bugzilla.mozilla.org/show_bug.cgi?id=1211610.
>

> I've got a test page here to confirm that it's turned on properly:
> http://people.mozilla.org/~bgirard/scroll_no_paint.html
>
> Scrolling on this page is slow in FF because it hits a performance bugs in
> layer construction code. However with APZ the scrolling is smooth and a bit
> checkerboard-y instead. If you have 'layers.acceleration.draw-fps' set you
> should notice the left most FPS counter at 60 FPS while the middle counter
> will be much lower. This is APZ handling the scroll.
>
> Happy Testing,
> Benoit

[Felipe G]

Hey Jonas,

this second issue that you're seeing is tracked at
https://bugzilla.mozilla.org/show_bug.cgi?id=1257862

Cheers,
Felipe

[Benoit Girard]

Thanks for helping test! Feel free to disable the feature for now since
right now enabling this has been de-prioritize for the time being while we
focus on shipping APZ and E10S.

On Tue, Mar 29, 2016 at 4:55 PM, Jonas Sicking <jo...@sicking.cc> wrote:

> Hi Benoit,
>
> There's two problems that I've seen related to scrolling, and so
> possibly the result of APZ.
>
> The most obvious one is that if the child process is busy doing
> things, then the scrollable area seems "sticky". When you start
> scrolling there's a noticeable delay before the page starts scrolling.
>

> My guess is that we send some message to the child process when
> scrolling is initiated and don't start scrolling until the child
> process responds (possibly with some form of timeout)?
>
> This isn't noticeable on the example page that you provided, possibly
> because the child process is quite responsive before we start the
> heavy painting operations.
>

Yes, this is how it's implemented and a design limitation. Given that the
design changed a lot since it was planned it might be possible to remove
this limitation down the road and have APZ initiate the scroll.

> The other problem, which is more serious, is that every now and then
> the browser seems to get into a state where I can't use the trackpad
> at all to do scrolling. The scroll bar is displayed, as is common when
> using the trackpad to scroll, but no scrolling actually happens.
>
> The only way I can scroll when the browser is in this state is to
> hover the scrollbar and click below the scroll thumb, which enables
> scrolling one page at a time.
>
> The only way to get out of the state is by restarting the browser.
>
> Sadly this happens very infrequently, so I haven't been able to create
> steps to reproduce, nor seen any pattern in where it triggers.
>

As Felipe points out this is a recent APZ regression and isn't tied to this
feature.

[Sam Harrington]

I've been seeing some rather weird middle-click scrolling behavior in recent nightlies, and your test page seems to be a good way to reproduce it (see https://gfycat.com/FarflungCoarseBoutu for a video). Is this a known issue, or should I file it?

[Kartikaya Gupta]

On Apr 1, 2016 2:45 AM, "Sam Harrington" <samuel.l....@gmail.com>
wrote:

> I've been seeing some rather weird middle-click scrolling behavior in
recent nightlies, and your test page seems to be a good way to reproduce it
(see https://gfycat.com/FarflungCoarseBoutu for a video). Is this a known
issue, or should I file it?

This sounds very similar to
https://bugzilla.mozilla.org/show_bug.cgi?id=1259781 (see the screencast
linked on that bug). If you think this is a different issue then please
file a new bug in the same component as that bug. Thanks!

kats

[march...@gmail.com]

Right now of FF 51 beta...it has issues/glitches if you scroll too fast (using scroll bar) and also Horizontal scroll bars are buged too (doesn't scroll properly)

[Botond Ballo]

On Wed, Jan 18, 2017 at 1:21 PM, <march...@gmail.com> wrote:
> Right now of FF 51 beta...it has issues/glitches if you scroll too fast (using scroll bar) and also Horizontal scroll bars are buged too (doesn't scroll properly)

Are you manually flipping the pref apz.drag.enabled in 51 beta?

So far we only enabled it by default on the Nightly channel, in 53 and
later. Several bugs related to it were fixed in 52 and 53, so if
you're testing in 51 you could be running into bugs that have already
been fixed.

Cheers,
Botond

[march...@gmail.com]

Yes I did...sorry I didn't realize....Right now I'm testing on 53 nightly from today...Horizontal scroll bars are fixed! but glitches if you scroll too fast (using vertical scroll bar) remains try http://www.diariouno.com.ar/ and scroll fast texts/news start to blink or dissapear. Thanks!

[Botond Ballo]

> glitches if you scroll too fast (using vertical scroll bar) remains try http://www.diariouno.com.ar/ and scroll fast texts/news start to blink or dissapear. Thanks!

This is a known issue, bug 1251617. Quoting from a recent post to
dev-platform about this [1]:

"This is hard to fix, and can be thought of as a conscious tradeoff:
we're deliberately allowing you to drag faster than we can paint the
content you're moving over."

Given that this is a tradeoff, I think we question we need to answer
is this: is scrollbar dragging being more responsive valuable enough
that it's worth seeing some checkerboarding (blank regions of content)
as you're doing it? If you have an opinion on this, please mention it
in the bug (or here).

Thanks,
Botond

[1] https://groups.google.com/d/msg/mozilla.dev.platform/_65Nu8PphT4/8bdobqxjEAAJ

[march...@gmail.com]

Hi botond i was testing a little with 53.0a1 (2017-01-23) (32-bit)... I found that the bug i told you before get worse when the web page has a fixed background image...it seems that FF is trying to calcute or paint the fixed background when its not needed.

A few days ago i was comparing scrolling on M.S. Edge and FF and i realize that if the web page has no fixed background image both perform exactly, with an acceptable delay on painting, but if the web page has a fixed background image, firefox shows glitches on that background image that Edge doesn't.

Example: http://www.localstrike.net/foros/ ... try to scroll fast and later use firefox's dev tools to remove the fixed attribute from the background image it works good exactly like M.S. Edge.

Thanks and sorry for my crappy english

[zbran...@mozilla.com]

Easily reproducible on Ubuntu 16.10, so cross platform.

Worth filling a bug?

zb.

[Botond Ballo]

> Hi botond i was testing a little with 53.0a1 (2017-01-23) (32-bit)... I found that the bug i told you before get worse when the web page has a fixed background image...it seems that FF is trying to calcute or paint the fixed background when its not needed.
>
> A few days ago i was comparing scrolling on M.S. Edge and FF and i realize that if the web page has no fixed background image both perform exactly, with an acceptable delay on painting, but if the web page has a fixed background image, firefox shows glitches on that background image that Edge doesn't.
>
> Example: http://www.localstrike.net/foros/ ... try to scroll fast and later use firefox's dev tools to remove the fixed attribute from the background image it works good exactly like M.S. Edge.

I do see checkerboarding on that page when dragging the scrollbar
quickly. While the checkerboarding itself is expected (bug 1251617),
the fact that the checkerboarding extends to the fixed background
image is not expected. I filed bug 1333965 [1] about this.

However, for me, making the background image not fixed does not
improve the behaviour.

Just to be sure: are you scrolling by dragging the scrollbar?

Thanks,
Botond

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1333965

[Botond Ballo]

> Easily reproducible on Ubuntu 16.10, so cross platform.

Do you also reproduce the improvement when the background is made not fixed?

Thanks,
Botond