connect-homes.com caching issue when loading in a secondary/background tab
Categories
(Core :: Graphics, defect, P3)
Tracking
()
People
(Reporter: cfogel, Unassigned)
References
(Regression, )
Details
(Keywords: correctness, regression)
Attachments
(1 file)
2.81 MB,
image/gif
|
Details |
Affected versions
- 80.0b1, 81.0a1(2020-07-29);
Affected platforms
- Windows 10, macOS 10.15;
Steps to reproduce
- clear cache if having accessed the website before;
- issue reproduces just for the first time the site is loaded with these STR;
- Launch Firefox;
- Open a tab, access any random web-page of choice;
- With that page in focus, drag the link to https://connect-homes.com/ so it would open in the background in a second tab;
- Wait until the page would load;
- Change to the second tab;
Expected result
- page loads;
Actual result
- page not loaded, not scroll-able; just background loaded;
- checking for regression the favicon wasn't loaded either in some cases;
Regression range
- First bad: 2020-07-23
- Last good: 2020-07-22;
- Pushlog: URL;
- Potential regressor: 1603676;
Additional notes
- attached recording with the issue;
- gfx.webrender.all was as default on false, same result when flipping it on;
- suggested severity is S4, since with a page refresh it's cleared(most people would do that anyway).
Reporter | ||
Comment 1•4 years ago
|
||
@ :sotaro mind confirming if the regressor is accurate?
Thanks!
Comment 2•4 years ago
•
|
||
It was easier to reproduce the problem with multiple background tabs opened like the following STR. The problem happened since more old days than Bug 1603676 with WebRender. And change of Bug 1603676 seems not related to this bug.
STR
- [1] Launch Firefox;
- [2] Open a tab with https://bugzilla.mozilla.org/show_bug.cgi?id=1656218
- [3] With that page in focus, drag the link to https://connect-homes.com/ multiple times(4-5times) so it would open in the background in multiple tabs
- [4] Wait until the page would load
- [5] Change to the background tabs
But the problem could not be reproduce reliably even with the STR.
Comment 3•4 years ago
|
||
I saw the problem even with the following command.
- ./mach mozregression --good 2016-09-15 --pref gfx.webrender.all:true gfx.webrender.enabled:true -a https://bugzilla.mozilla.org/show_bug.cgi?id=1656218
Reporter | ||
Comment 4•4 years ago
|
||
From what I noticed, the issue can be reproduced consistently(er) on the first run/load or with a fresh profile so the site data isn't cached.
Opening in Private browsing mode also helped.
Updated•4 years ago
|
Comment 5•4 years ago
|
||
The severity field is not set for this bug.
:ktaeleman, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•4 years ago
|
Comment 6•4 years ago
|
||
I think this should not be a networking issue.
Move this to DOM to see why the page is loaded but not rendered.
Updated•4 years ago
|
Comment 7•4 years ago
|
||
The content ends up in the DOM OK. Dev tools show that the elements get their correct layout dimensions. They just don't get painted. This looks like a graphics problem to me, but since this bug already was in graphics, let's try layout next.
Comment 8•4 years ago
|
||
This is in fact a graphics issue, specially if it only happens with WR. I don't know why it was moved? Kris?
Comment 9•4 years ago
•
|
||
Reproducible with Basic and WebRender on Gnome Xwayland. Wait 5 seconds before switching tabs to make it 100% reproducible on first try.
mozregression --launch 2020-08-25 --pref gfx.webrender.all:true -a https://bugzilla.mozilla.org/show_bug.cgi?id=1656218#c2
mozregression --launch 2020-08-25 --pref gfx.webrender.force-disabled:true -a https://bugzilla.mozilla.org/show_bug.cgi?id=1656218#c2
2020-01-25, 2019-01-15, 2018-07-01 are also affected.
mozregression --good 2018-01-15 --bad 2018-07-01 --pref gfx.webrender.force-disabled:true -a https://bugzilla.mozilla.org/show_bug.cgi?id=1656218#c2
10:02.37 INFO: Last good revision: 718e04535230d53a590b7dbb1a3cd983c259a622 (2018-03-12)
10:02.37 INFO: First bad revision: c56ef1c14a555023949ad727c86e3c2df995edd2 (2018-03-13)
10:02.37 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=718e04535230d53a590b7dbb1a3cd983c259a622&tochange=c56ef1c14a555023949ad727c86e3c2df995edd2
Disabling tab warming does not help:
mozregression --launch 2020-08-25 --pref gfx.webrender.force-disabled:true browser.tabs.remote.warmup.enabled:false -a https://bugzilla.mozilla.org/show_bug.cgi?id=1656218#c2
Disabling APZ doesn't help:
mozregression --launch 2020-08-25 --pref gfx.webrender.force-disabled:true browser.tabs.remote.warmup.enabled:false layers.async-pan-zoom.enabled:false -a https://bugzilla.mozilla.org/show_bug.cgi?id=1656218#c2
Last good seems correct:
mozregression --launch 2018-03-12 --pref gfx.webrender.force-disabled:true -a https://bugzilla.mozilla.org/show_bug.cgi?id=1656218#c2
Comment 10•4 years ago
|
||
Disabling tab warming does not help:
mozregression --launch 2020-08-25 --pref gfx.webrender.force-disabled:true browser.tabs.remote.warmup.enabled:false -a https://bugzilla.mozilla.org/show_bug.cgi?id=1656218#c2
Disabling tab warming doesn't help today anymore, but it fixes the problem on first bad build:
mozregression --launch 2018-03-13 --pref gfx.webrender.force-disabled:true browser.tabs.remote.warmup.enabled:false -a https://bugzilla.mozilla.org/show_bug.cgi?id=1656218#c2
64c633802d4cd0e2c32a271a2d29107b5b43f38 Mike Conley — Bug 1423220 - Enable tab warming by default for Nightly builds. r=dao
Comment 11•4 years ago
|
||
Moving back to Graphics. I remember moving it because it occured with both WR and non-WR, and when site was not cached, causing me to conclude it was not graphics related. I'll add it to our triaging discussion list.
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Description
•