Happens unreliably, seemingly on many websites. Sometimes I will scroll and the content won't paint for a few seconds. Moving the mouse cursor over the unpainted area often seems to trigger scrolling. Testing on a recent MBP with current Nightly

Just experienced this on twitter.com. Counted 30 seconds of not-painting. Moved the mouse cursor over and it painted instantly.

could be related to bug 1437374

I saw this on the advanced search page on Bugzilla. STR: 1. Visit: https://bugzilla.mozilla.org/query.cgi?format=advanced 2. Select "Toolkit" with a mouse from the "Product" section 3. Scroll the "Component" section. Somewhat embarrassing STR: 1. Visit: http://khhair-nottingham.co.uk/khhair_nottingham_bookonline.html 2. Click mylocalsalon banner 3. In the new tab pick a service (mens dry cut), then click next 4. Click next again Expected: To render "previous" button, last time slot. If this doesn't reproduce, refreshing this page a few times produced after 4. helps.

I'm on Ubuntu 17.10 with a Dell XPS. Name Firefox Version 60.0a1 Build ID 20180214224814 Update History Update Channel nightly User Agent Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 OS Linux 4.13.0-32-generic

I'm not able to reproduce with jkt's STR (on my Windows laptop). I saw a similar problem intermittently on the Hacker News home page: 1. I loaded https://news.ycombinator.com/ 2. The page loaded and painted as expected. 3. I scrolled the page and some of the story titles were missing, but their story number and meta data were rendered. 4. I scrolled some more and then the story titles appeared. I've only see this problem once or twice on Hacker News, but I've seen similar problems this week on Bugzilla and some other websites. Hacker News uses a giant HTML table for layout, so perhaps this problem is related to bug 1436698.

This might be a dupe of bug 1437374.

Are either of you using multiple screens? I just noticed after: Disconnecting my screen, suspending my computer, log back in and browse sites like https://treeherder.mozilla.org that was already open.

(In reply to Jonathan Kingston [:jkt] from comment #7) > Are either of you using multiple screens? I just noticed after: > > Disconnecting my screen, suspending my computer, log back in and browse > sites like https://treeherder.mozilla.org that was already open. I frequently switch between internal and an external monitor but I can't say it feel like doing so causes this.

(In reply to Jonathan Kingston [:jkt] from comment #3) > I saw this on the advanced search page on Bugzilla. > STR: > 1. Visit: https://bugzilla.mozilla.org/query.cgi?format=advanced > 2. Select "Toolkit" with a mouse from the "Product" section > 3. Scroll the "Component" section. > > Somewhat embarrassing STR: > 1. Visit: http://khhair-nottingham.co.uk/khhair_nottingham_bookonline.html > 2. Click mylocalsalon banner > 3. In the new tab pick a service (mens dry cut), then click next > 4. Click next again > > Expected: > To render "previous" button, last time slot. > > If this doesn't reproduce, refreshing this page a few times produced after > 4. helps. can you recheck with the lsatest nightly? bug 1437374 is fixed now.

I can't replicate anymore on those sites, did something change?

I'm still seeing this in the currently nightly

(In reply to Jonathan Kingston [:jkt] from comment #10) > I can't replicate anymore on those sites, did something change? bug 1437374 got fixed, which probably fixed this bug as well.

Dave, is this still around?

(In reply to Milan Sreckovic [:milan] from comment #13) > Dave, is this still around? Yes

Is there any way to help diagnose this issue from an opt build?

If issue will be gone with setting to "false" this preference "layout.display-list.retain" in about:config, it could be similar issue as bug #1422274 or even duplicate. Can you please confirm this?

(In reply to Virtual_ManPL [:Virtual] - (please needinfo? me - so I will see your comment/reply/question/etc.) from comment #16) > If issue will be gone with setting to "false" this preference > "layout.display-list.retain" in about:config, it could be similar issue as > bug #1422274 or even duplicate. The bug descriptions sound similar. I still see this scrolling issue, but it is very intermittent. So even if set the "layout.display-list.retain" pref to false, I wouldn't know whether the pref fixed the problem or I just had randomly did not hit the problem. But I will test the pref.

(In reply to Chris Peterson [:cpeterson] from comment #17) > (In reply to Virtual_ManPL [:Virtual] - (please needinfo? me - so I will see > your comment/reply/question/etc.) from comment #16) > > If issue will be gone with setting to "false" this preference > > "layout.display-list.retain" in about:config, it could be similar issue as > > bug #1422274 or even duplicate. > > The bug descriptions sound similar. I still see this scrolling issue, but it > is very intermittent. So even if set the "layout.display-list.retain" pref > to false, I wouldn't know whether the pref fixed the problem or I just had > randomly did not hit the problem. But I will test the pref. See if it fixes the bug(it does on my laptop)(In reply to Dave Townsend [:mossop] from comment #0) > Happens unreliably, seemingly on many websites. Sometimes I will scroll and > the content won't paint for a few seconds. Moving the mouse cursor over the > unpainted area often seems to trigger scrolling. > > Testing on a recent MBP with current Nightly can you just test with a new profile and only change browser.tabs.remote.autostart=false Can you still reproduce it?

(In reply to Emilio from comment #18) > can you just test with a new profile and only change > > browser.tabs.remote.autostart=false > > Can you still reproduce it? This will disable completely e10s (Electrolysis), which isn't good idea and won't help much to find cause, even if it helps.

I've noticed that this behaviour of only partial / incomplete painting is much more common for me in the Gecko Profiler popup. Is that useful data, or a red herring?

(In reply to Virtual_ManPL [:Virtual] - (please needinfo? me - so I will see your comment/reply/question/etc.) from comment #19) > (In reply to Emilio from comment #18) > > can you just test with a new profile and only change > > > > browser.tabs.remote.autostart=false > > > > Can you still reproduce it? > > This will disable completely e10s (Electrolysis), which isn't good idea and > won't help much to find cause, even if it helps. Sure it does, i narrows it down

(In reply to Mike Conley (:mconley) (:⚙️) (Totally backlogged on reviews and needinfos) from comment #20) > I've noticed that this behaviour of only partial / incomplete painting is > much more common for me in the Gecko Profiler popup. Is that useful data, or > a red herring? Could be same issue or not, see: Comment #16, bug #1447193 and bug #1422274. (In reply to Emilio from comment #21) > Sure it does, i narrows it down No, as e10s (Electrolysis) was enabled by default for years now, so there is really no point in doing that, because it won't bring us any information about regression range. If it is for you, please explain.

(In reply to Virtual_ManPL [:Virtual] - (please needinfo? me - so I will see your comment/reply/question/etc.) from comment #16) > If issue will be gone with setting to "false" this preference > "layout.display-list.retain" in about:config, it could be similar issue as > bug #1422274 or even duplicate. > > Can you please confirm this? I still see this with layout.display-list.retain=false

(In reply to Dave Townsend [:mossop] from comment #23) > (In reply to Virtual_ManPL [:Virtual] - (please needinfo? me - so I will see > your comment/reply/question/etc.) from comment #16) > > If issue will be gone with setting to "false" this preference > > "layout.display-list.retain" in about:config, it could be similar issue as > > bug #1422274 or even duplicate. > > > > Can you please confirm this? > > I still see this with layout.display-list.retain=false Thank you very much. One more test. Please see if issue will be gone with setting to "false" this preference "browser.tabs.remote.warmup.enabled" in about:config.

(In reply to Virtual_ManPL [:Virtual] - (please needinfo? me - so I will see your comment/reply/question/etc.) from comment #24) > One more test. > Please see if issue will be gone with setting to "false" this preference > "browser.tabs.remote.warmup.enabled" in about:config. With "browser.tabs.remote.warmup.enabled" set to false, I can still reproduce the issue by fast scrolling webpages.

(In reply to Peja Stija from comment #25) > With "browser.tabs.remote.warmup.enabled" set to false, I can still > reproduce the issue by fast scrolling webpages. When you fast-scroll pages, does the content repaint within a few hundred milliseconds, or do you have to wait multiple-seconds? If it's only a few hundred milliseconds, that might be standard checkerboarding. For the people who were experiencing this a month ago, did you enable tab warming before it was enabled by default on Nightly? If so, this sounds awfully similar to bug 1447193...

I had this preference enabled since December. I can´t remember when this problem begun. Maybe at first I didn´t notice. Lately this was getting quite annoying. I have been trying to change several preferences for a while and none of them resolved the problem. I didn´t try this one. When Alice0775 White in Bug 1447193 mention "browser. tabs. remote. warmup. enabled" 3 days ago I disabled it and since then I didn´t notice anymore this bug.

(In reply to Virtual_ManPL [:Virtual] - (please needinfo? me - so I will see your comment/reply/question/etc.) from comment #24) > (In reply to Dave Townsend [:mossop] from comment #23) > > (In reply to Virtual_ManPL [:Virtual] - (please needinfo? me - so I will see > > your comment/reply/question/etc.) from comment #16) > > > If issue will be gone with setting to "false" this preference > > > "layout.display-list.retain" in about:config, it could be similar issue as > > > bug #1422274 or even duplicate. > > > > > > Can you please confirm this? > > > > I still see this with layout.display-list.retain=false > > Thank you very much. > > One more test. > Please see if issue will be gone with setting to "false" this preference > "browser.tabs.remote.warmup.enabled" in about:config. It's difficult to say since this is difficult to reproduce but I think this solved it

(In reply to Mike Conley (:mconley) (:⚙️) (Totally backlogged on reviews and needinfos) from comment #26) > (In reply to Peja Stija from comment #25) > > With "browser.tabs.remote.warmup.enabled" set to false, I can still > > reproduce the issue by fast scrolling webpages. > > When you fast-scroll pages, does the content repaint within a few hundred > milliseconds, or do you have to wait multiple-seconds? > > If it's only a few hundred milliseconds, that might be standard > checkerboarding. > > For the people who were experiencing this a month ago, did you enable tab > warming before it was enabled by default on Nightly? If so, this sounds > awfully similar to bug 1447193... Actually, It went A LOT better after setting "browser.tabs.remote.warmup.enabled" to false AND a browser restart. I didn't notice the issue anymore since a full day with that setting disabled.

(In reply to Peja Stija from comment #29) > Actually, It went A LOT better after setting > "browser.tabs.remote.warmup.enabled" to false AND a browser restart. > I didn't notice the issue anymore since a full day with that setting > disabled. Thanks, Peja. I have some builds in bug 1447193 comment 15 that might fix this issue. Can you please reset that preference to true, and then see if you still see the bug with either of those builds?

(In reply to Mike Conley (:mconley) (:⚙️) (Totally backlogged on reviews and needinfos) from comment #30) > (In reply to Peja Stija from comment #29) > > Actually, It went A LOT better after setting > > "browser.tabs.remote.warmup.enabled" to false AND a browser restart. > > I didn't notice the issue anymore since a full day with that setting > > disabled. > > Thanks, Peja. I have some builds in bug 1447193 comment 15 that might fix > this issue. Can you please reset that preference to true, and then see if > you still see the bug with either of those builds? Hello Mike, With the 32bit version from bug 1447193 comment 15 and "browser.tabs.remote.warmup.enabled" = true, I still haven't encountered the issue on a bunch of simple forums I mostly encounter it multiple times an hour. Fast scrolling and all is painting fine & dandy. Issue seems to be fixed with that build.

(In reply to Dave Townsend [:mossop] from comment #28) > > One more test. > > Please see if issue will be gone with setting to "false" this preference > > "browser.tabs.remote.warmup.enabled" in about:config. > > It's difficult to say since this is difficult to reproduce but I think this > solved it Thank you very much! I will mark this bug, as duplicate of bug #1447193 per regression range, more information and possible patch. I hope you don't mind. + clearing :ni per resolved status