Closed Bug 1416847 Opened 7 years ago Closed 6 years ago

Buggy scrollbar on a certain site with webrender

Categories

(Core :: Graphics: WebRender, defect, P1)

defect

Tracking

()

VERIFIED FIXED
Tracking Status
firefox-esr52 --- unaffected
firefox56 --- unaffected
firefox57 --- unaffected
firefox58 --- unaffected
firefox59 --- unaffected
firefox60 --- disabled

People

(Reporter: noszalyaron4, Assigned: botond)

References

(Blocks 1 open bug, )

Details

(Keywords: nightly-community, Whiteboard: [wr-reserve] [gfx-noted])

Attachments

(2 files, 1 obsolete file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20171113100232

Steps to reproduce:

First I enabled gfx.webrender.blog-images, gfx.webrender.enabled and layers.acceleration.force-enabled.

Then I navigated to https://prog.hu/tarsalgo/199987/c-beadando-tul-lassu?no=37#e37

To reproduce issue click on the vertical bar that says "Mutasd a teljes hozzászólást!" ("Show the full comment" in hungarian). Then try to drag the scrollbar that just appeared. The result is like pressing End button.

Ps.: I'm using Firefox 59 nightly but I can't yet report bugs to it. 



Expected results:

The bar should've just moved the inner content as like in chrome and firefox without webrender.
Component: Untriaged → Graphics: WebRender
Product: Firefox → Core
Thank you! Confirmed in
Nightly 59 x64 20171113100232 de_DE fc194660762d1b92e1679d860a8bf41116d0f54f @ Debian Testing (KDE, Radeon RX480).
fresh profile: layers.acceleration.force-enabled, gfx.webrender.enabled

(As described: A click itself doesn't trigger this bug, but dragging the scrollbar does it.)

Fixed by disabling WebRender.
Status: UNCONFIRMED → NEW
Has STR: --- → yes
Ever confirmed: true
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
Whiteboard: [wr-mvp] [triage]
Version: 58 Branch → Trunk
Attached video 2017-11-13_19-52-54.mp4
Whiteboard: [wr-mvp] [triage] → [wr-mvp] [triage][wr-reserve-candidate]
Priority: -- → P3
Whiteboard: [wr-mvp] [triage][wr-reserve-candidate] → [wr-reserve]
Whiteboard: [wr-reserve] → [wr-reserve] [gfx-noted]
OS: Linux → All
Hardware: x86_64 → All
Assignee: nobody → botond
I can reproduce this issue.
The site appears to have disappeared - it just redirects to https://www.torproject.org/ now.
Can't "reproduce" :) For me it loads fine.
Interesting. I'm not sure what's going on, but the fact that you can access the page still is good news!

Could you please:

  1. File -> Save Page As -> Web page, complete
  2. Zip up everything that's downloaded
  3. Attach the zip file to this bug

Thanks!
Attached file bug.zip (obsolete) —
Here's it. Unfortunately the site is kind of broken so I had to click on the bar which shows the full comment then download because otherwise it wouldn't do anything in the downloaded version (somekind of js is broken probably because the content is still in the source as far as I saw).
Attached file bug1416847.zip
Thanks! I had to fix up the filenames to get the page to load properly (see updated attachment), but with that change I can reproduce the problem locally now.
Attachment #8940310 - Attachment is obsolete: true
The proximate cause of the problem is that the wrong APZC is handling the drag events - the APZC for the page (root scroll frame) is handling them, even though it's the subframe's scrollbar that's being dragged.

When the mouse-down event is processed by APZ, the subframe is not layerized (nor is its scrollbar thumb), so the page's APZC is hit (this in and of itself is fine). However, the hit result does not include the dispatch-to-content flag, so the page's APZC is marked as the confirmed target APZC for the drag input block (this is problematic).

I'm continuing to investigate.
I feel quite silly for not trying this sooner, but it turns out that turning the pref gfx.webrender.hit-test on fixes this problem. Marking this dependent on the bug that tracks enabling the pref by default.
Depends on: 1425745
(Whoops, wrong bug number.)
Depends on: 1421380
No longer depends on: 1425745
This should be fixed by bug 1421380.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Debian Testing (KDE, Radeon RX480)

Reusing the fix range from bug 1425745 comment 9.
Comment 2 shows what "bad" is.

should be good:
mozregression --repo autoland --launch 5fc179e245d51289f1f7bcaba0c29189d3336fbf --pref gfx.webrender.all:true startup.homepage_welcome_url:"https://prog.hu/tarsalgo/199987/c-beadando-tul-lassu?no=37#e37"
-> good

should be bad:
mozregression --repo autoland --launch ca489678fdedaff1c660dddf7ee62c966787b59a --pref gfx.webrender.all:true startup.homepage_welcome_url:"https://prog.hu/tarsalgo/199987/c-beadando-tul-lassu?no=37#e37"
-> bad

Fixed by:
> 5fc179e245d5	Kartikaya Gupta — Bug 1421380 - Enable gfx.webrender.hit-test by default. r=jrmuizel
> c182e492a2e7	Kartikaya Gupta — Bug 1421380 - Don't do a composite of WR rendered frames unless a composite is requested. r=nical
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: