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)
Core
Graphics: WebRender
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.
Updated•7 years ago
|
Component: Untriaged → Graphics: WebRender
Product: Firefox → Core
Comment 1•7 years ago
|
||
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
status-firefox56:
--- → unaffected
status-firefox57:
--- → unaffected
status-firefox58:
--- → unaffected
status-firefox-esr52:
--- → unaffected
Ever confirmed: true
Keywords: nightly-community
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
Whiteboard: [wr-mvp] [triage]
Version: 58 Branch → Trunk
Comment 2•7 years ago
|
||
Updated•7 years ago
|
Blocks: stage-wr-nightly
Whiteboard: [wr-mvp] [triage] → [wr-mvp] [triage][wr-reserve-candidate]
Updated•7 years ago
|
Priority: -- → P3
Whiteboard: [wr-mvp] [triage][wr-reserve-candidate] → [wr-reserve]
Updated•7 years ago
|
Whiteboard: [wr-reserve] → [wr-reserve] [gfx-noted]
Updated•7 years ago
|
OS: Linux → All
Hardware: x86_64 → All
Updated•7 years ago
|
Blocks: webrender-site-issues
Updated•6 years ago
|
Priority: P3 → P1
Updated•6 years ago
|
Assignee: nobody → botond
Assignee | ||
Comment 4•6 years ago
|
||
I can reproduce this issue.
Assignee | ||
Comment 5•6 years ago
|
||
The site appears to have disappeared - it just redirects to https://www.torproject.org/ now.
Reporter | ||
Comment 6•6 years ago
|
||
Can't "reproduce" :) For me it loads fine.
Assignee | ||
Comment 7•6 years ago
|
||
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!
Reporter | ||
Comment 8•6 years ago
|
||
Reporter | ||
Comment 9•6 years ago
|
||
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).
Assignee | ||
Comment 10•6 years ago
|
||
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
Assignee | ||
Comment 11•6 years ago
|
||
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.
Assignee | ||
Comment 12•6 years ago
|
||
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
Assignee | ||
Comment 13•6 years ago
|
||
(Whoops, wrong bug number.)
Comment 14•6 years ago
|
||
This should be fixed by bug 1421380.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Comment 15•6 years ago
|
||
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
You need to log in
before you can comment on or make changes to this bug.
Description
•