1355376 - Scrolling in <listbox> elements leaves white area that doesn't respond to scrolling

Status: VERIFIED FIXED

(Core :: Panning and Zooming, defect, P3)

Description

[684sigma]

I found a problem in Nightly 55. It doesn't happen in Beta 53.
Sometimes when scrolling a scrollable area up, scrollbar moves down, and vice versa. Here's how to reproduce it:

1. Open about:preferences#advanced
2. Slowly drag scrollbar in "Offline web content and user data" section from top to bottom and back to the top.
3. Slowly drag scrollbar in "Offline web content and user data" section from top to bottom.
4. Move mouse over the empty area that appeared in that section, rotate mouse wheel up. Rotate mouse wheel down.

Result: Empty area appears in <listbox> element. It doesn't react to scrolling up with mouse wheel, but it reacts to scrolling down with mouse wheel, as if the browser thought that <listbox> element is still scrolled to the top.

Expected: Normal scrolling (no empty area; scrolling with mouse wheel should work)

Happens with all <listbox> elements.

Comment 1

[684sigma]

Forgot to list sites that store offline data (copied from Bug 1344339):

http://html5demos.com/offlineapp
http://appcache-demo.s3-website-us-east-1.amazonaws.com/with-network/
http://www.spritecow.com/
http://everytimezone.com/
http://web.telegram.org/
http://lagged.com/play/501/ (you need to wait until the ad finishes)


Mozregression-gui generated this regression range:
(in fact I only checked the last good and first bad builds in regression range from Bug 1355374)
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=4cbc57e29e25e8abe783b16915bd74325a040b02&tochange=d7518eef6b8924b4ddad6cdeeae4eed1c6129b26
->
1324117 – Enable APZ scrollbar dragging on Nightly
https://bugzilla.mozilla.org/show_bug.cgi?id=1324117


And also it's not reproducible after setting apz.drag.enabled to false. (The pref seems to take effect without restart)

Comment 2

[ovidiu boca[:Ovidiu]]

Based on the regression range from comment 1, FF 53 is also affected.

Comment 3

[Kartikaya Gupta (email:[e-mail])]

This is nightly-only, depends on apz.drag.enabled being true. I can repro on Windows. Really weird behaviour, thanks for finding it!

Comment 4

[Mike Taylor [:miketaylr]]

(marking as fix-optional for 55 since this is a nightly-only feature and blocks 1352312, which is the bug to ship by default)

Comment 5

[Mike Taylor [:miketaylr]]

(oops... blocks 1211610)

Comment 6

[Botond Ballo [:botond]]

I think the <listbox> referred to in the original STR has recently been removed from the preferences UI, but I could reproduce the problem with another <listbox> in the browser chrome. Revised STR:

  1. Open History -> Show All History
  2. Create ~20 tags (e.g. by selecting Today, selecting a history item, and 
     adding 20 comma-separated tags in the "Tags" field.
  3. In All Bookmarks -> Other Bookmarks, select a bookmark.
  4. In the bottom pane, next to the "Tags" field, press the down-arrow button
     to expand the list of tags. This is a <listbox>.
  5. Scroll the <listbox> as described in the original STR.

I don't think XUL <listbox> was designed to be async-scrolled. Trying to async-scroll one via touch events on a touchscreen laptop triggers the same behaviour.

Comment 7

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #6)
> I don't think XUL <listbox> was designed to be async-scrolled. Trying to
> async-scroll one via touch events on a touchscreen laptop triggers the same
> behaviour.

The reason wheel scrolling isn't affected is that the listbox prevent-defaults all wheel events. It does not, however, prevent-default touch events or mouse events associated with scrollbar dragging.

Comment 8

[Botond Ballo [:botond]]

Attachment: Bug 1355376 - Do not use async scrollbar dragging for scroll frames with custom scrollbar mediators.

Supporting custom scrollbar mediators would require having custom logic in APZ
for each custom mediator. Since custom mediators are only used by legacy XUL
elements (<listbox> and <tree>) that isn't worth implementing.

Review commit: https://reviewboard.mozilla.org/r/132574/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/132574/

Comment 9

[Markus Stange [:mstange]]

Comment on attachment 8860560 [details]
Bug 1355376 - Do not use async scrollbar dragging for scroll frames with custom scrollbar mediators.

https://reviewboard.mozilla.org/r/132574/#review135462

::: layout/xul/nsSliderFrame.cpp:1038
(Diff revision 1)
> +  if (nsIScrollbarMediator* mediator = scrollbarFrame->GetScrollbarMediator()) {
> +    nsIScrollableFrame* scrollFrame = do_QueryFrame(mediator);
> +    // The scrollbar mediator is not the scroll frame.
> +    // That means this scroll frame has a custom scrollbar mediator.
> +    // That's not supported in the APZ codepath.
> +    if (scrollFrame == nullptr) {

I think our style guide asks for this to be an if (!scrollFrame).

Comment 10

[Botond Ballo [:botond]]

Comment on attachment 8860560 [details]
Bug 1355376 - Do not use async scrollbar dragging for scroll frames with custom scrollbar mediators.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/132574/diff/1-2/

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/48503ae4cbd6
Do not use async scrollbar dragging for scroll frames with custom scrollbar mediators. r=mstange

Comment 12

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #6)
> I don't think XUL <listbox> was designed to be async-scrolled. Trying to
> async-scroll one via touch events on a touchscreen laptop triggers the same
> behaviour.

Filed bug 1359211 for the issue with touch-scrolling.

Comment 13

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/48503ae4cbd6

Comment 14

[ovidiu boca[:Ovidiu]]

Attachment: Recording #29.mp4

In order to see the "Offline web content and user data" section from about:preferences#privacy you need to set browser.preferences.offlineGroup.enabled to true.

To verify this issue I set the preference on true and followed the scenario from the description. I don't see any empty area and scrolling with mouse wheel works. The only problem occurs when you grab the scrollbar and try to move it up and down, this move is not smooth. I attached a screen recorder with the issue, I'm not sure how helpful it is.  

The test was performed on Mac OS X 10.10 with FF Nightly 55.0a1(2017-04-25)

Comment 15

[Kartikaya Gupta (email:[e-mail])]

(In reply to ovidiu boca[:Ovidiu] from comment #14)
> The only problem occurs when you grab the scrollbar and try to
> move it up and down, this move is not smooth. I attached a screen recorder
> with the issue, I'm not sure how helpful it is.  

Thanks, the recording was helpful. The behaviour you see is intentional, the listbox always scroll by a "line" amount, so that the top entry is never half-visible. That's what you are seeing when dragging the scrollbar.

Comment 16

[ovidiu boca[:Ovidiu]]

I verified this issue on Mac OS X 10.10, Windows 10 x64 and Ubuntu 14.04 and I'm not able to reproduce this anymore. Based on that I will mark this as a verified fix.