Open Bug 1502334 Opened 3 years ago Updated 3 years ago
Reddit content is no longer displayed when scrolled with a keyboard
[Affected versions]: - Fx63.0 RC - Fx64.0b4 - Fx65.0a1 [Affected platforms]: - Windows 10 x64 [Steps to reproduce]: 1. Launch Firefox. 2. Go to www.reddit.com 3. Scroll the page down to load a lot of post (create a long redered post list available for scrolling using the keyboard). 4. Start scrolling up using the keyboard by pressing the 'up' arrow. [Expected result]: - Scroll operation is done smoothly and without any issues. [Actual result]: - At some point the content disappears, only a grey background is displayed. [Regression range]: - I will come back with a regression rage ASAP. [Additional notes]: - The issue does not occur on macOS or Ubuntu. - For some reason, when using a screen recorder(OBS Studio in my case), the issue stops happening.
I suspect this is something broken in our Async Panning & Zooming code (or possibly graphics/painting, given that a screen recorder makes the problem go away, presumably by prompting more aggressive screen-repainting). A regression window would be super-useful for tracking down the issue here!
Component: Layout: Scrolling and Overflow → Panning and Zooming
Last known good build: 2016-05-30 First known bad build: 2016-05-31 Best I could narrow it down to was this change set: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3435dd7ad71fe9003bdeee18fd38d815e033beef&tochange=111970c738234569c8c180319155327316335deb
Too late to fix in 63 but we could still take a patch for 65 (and maybe 64).
In that range, bug 1274528 jumps out as possibly-related. (It's entirely believable that the STR here cause us to reach the limit on active layers, and hence that bug 1274528 would've caused a change in behavior for this STR.)
Component: Panning and Zooming → Graphics: Layers
I doubt that bug 1274528 is responsible - layers.max-active only affects android (it is infinite on desktop), and there's not very many layers on reddit, and that change makes us less likely to hit any limit. Having said that, there's nothing else in that range immediately sticking out to me. I'll investigate further.
I tried bisecting myself. While I'm not confident in what I found, as I'm only able to reproduce sporadically, I did reproduce on several builds earlier than the regression range posted above. The earliest I reproduced on was 2016-03-23, but as I said, I'm not confident this is the when the problem was introduced
I'm actually able to reproduce this on my Linux machine too, and on windows with the old compositor, advanced layers, or webrender. I think the problem here is that the network is too slow at loading new content as you scroll. If I throttle the network in devtools the problem seems to be much more pronounced. Here's a profile, in which the problem occurred at the end for a second or two, then the content became visible again right before I captured the profile: https://perfht.ml/2zyL182 Here's a profile in which I managed to capture before the content became visible again: https://perfht.ml/2zAukJx The painting and compositing looks fine in both, except for at the end in the first one there's a large gap between 2 composites, with a fairly long style, reflow, and rasterize time. Note that the problem had already occurred by this stage though. Since so much content had changed since the last paint, it's not surprising it took a little longer than usual. I'm fairly confident this isn't a gfx issue, but don't know how to investigate it any further.
Component: Graphics: Layers → DOM: Networking
Flags: needinfo?(jbonisteel) → needinfo?(sdeckelmann)
Flags: needinfo?(sdeckelmann) → needinfo?(honzab.moz)
Priority: -- → P2
Assignee: nobody → honzab.moz
Component: DOM: Networking → Graphics: Layers
Flags: needinfo?(honzab.moz) → needinfo?(kats)
Flags: needinfo?(honzab.moz) → needinfo?(pascalc)
Assignee: honzab.moz → nobody
You need to log in before you can comment on or make changes to this bug.