Closed Bug 1355376 Opened 3 years ago Closed 3 years ago

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

Categories

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

55 Branch
defect

Tracking

()

VERIFIED FIXED
mozilla55
Tracking Status
firefox52 --- unaffected
firefox-esr52 --- unaffected
firefox53 --- unaffected
firefox54 --- unaffected
firefox55 --- verified

People

(Reporter: 684sigma, Assigned: botond)

References

Details

(Keywords: regression, Whiteboard: [gfx-noted])

Attachments

(2 files)

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.
Has STR: --- → yes
Keywords: regression
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)
Blocks: 1324117
Has Regression Range: --- → yes
Component: Untriaged → Panning and Zooming
Product: Firefox → Core
Based on the regression range from comment 1, FF 53 is also affected.
This is nightly-only, depends on apz.drag.enabled being true. I can repro on Windows. Really weird behaviour, thanks for finding it!
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Unspecified → All
Priority: -- → P3
Hardware: Unspecified → All
Whiteboard: [gfx-noted]
(marking as fix-optional for 55 since this is a nightly-only feature and blocks 1352312, which is the bug to ship by default)
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.
Assignee: nobody → 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 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).
Attachment #8860560 - Flags: review?(mstange) → review+
Pushed by bballo@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/48503ae4cbd6
Do not use async scrollbar dragging for scroll frames with custom scrollbar mediators. r=mstange
See Also: → 1359211
(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.
https://hg.mozilla.org/mozilla-central/rev/48503ae4cbd6
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
Attached video 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)
(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.
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.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.