Cannot scroll with keyboard on result page of google search when non-WebRender
Categories
(Core :: Panning and Zooming, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | unaffected |
firefox82 | --- | unaffected |
firefox83 | + | fixed |
firefox84 | + | fixed |
People
(Reporter: alice0775, Assigned: tnikkel)
References
(Regression)
Details
(Keywords: nightly-community, regression)
Attachments
(3 files)
[Tracking Requested - why for this release]: scroll with keyboard is broken if non-WebRender
Reproducible: always
Steps to reproduce:
- Set gfx.webrender.force-disabled to true in about config
OR
Set layers.acceleration.disabled to true - Restart browser
- Type "? mozilla" (without quotation marks) in address bar and hit enter
- Try scroll with keyboard
Actual Results:
Page would not scroll.
Expected Results:
Page should scroll.
Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=cab81767be70469b780cd372ff463df59c2264e0&tochange=32a2e59ab7260118d8d5f430e503967fad6993cf
Before land Bug 1657822 : Bug 1674802
After land Bug 1657822 : this bug appears
Updated•4 years ago
|
Comment 1•4 years ago
|
||
Timothy, your patch in bug 1657822 seems to have caused this regression. Could you look and tell us if this needs fixing before we ship 83? Thanks
Comment 2•4 years ago
|
||
I investigated this a bit just now. It looks like the page structure is making it so that this NotifyApzTransaction() call is getting run and clearing out the pending ScrollPositionUpdate without it actually getting sent over in the paint transaction.
Assignee | ||
Comment 3•4 years ago
|
||
I have a potential fix for this but try server seemed upset in general, not at my patch, this evening
Updated•4 years ago
|
Assignee | ||
Comment 4•4 years ago
|
||
Scroll frames can appear in multiple containers.
Notifying the scroll frame causes it to clear it list of scroll updates. So we lose the scroll updates prematurely.
Previously https://phabricator.services.mozilla.com/D88650 moved the notify from happening the first time the scroll frame was encountered in a container to when the container is finished.
This patch moves this handling out of the container state and into FrameLayerBuilder.
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 6•4 years ago
|
||
Filed bug 1675709 to ensure the webrender code path can't suffer the same problem.
Comment 7•4 years ago
|
||
bugherder |
Assignee | ||
Comment 8•4 years ago
|
||
Comment on attachment 9185820 [details]
Bug 1674935. Collect and notify scroll frame in nsDisplayListBuilder not in ContainerState. r?mattwoodrow
Beta/Release Uplift Approval Request
- User impact if declined: (main thread initiated) scrolling doesn't work on some pages
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: No
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): I specifically crafted the patch to be low risk, moving further fixes into bug 1675709
- String changes made/needed:
Comment 9•4 years ago
|
||
Comment on attachment 9185820 [details]
Bug 1674935. Collect and notify scroll frame in nsDisplayListBuilder not in ContainerState. r?mattwoodrow
Approved for 83.0b10.
Comment 10•4 years ago
|
||
bugherder uplift |
Assignee | ||
Comment 12•4 years ago
|
||
Comment 13•4 years ago
|
||
Comment 14•4 years ago
|
||
bugherder |
Assignee | ||
Comment 15•4 years ago
|
||
Comment 16•4 years ago
|
||
Comment 17•4 years ago
|
||
bugherder |
Updated•4 years ago
|
Description
•