Open Bug 1656218 Opened 4 years ago Updated 3 years ago caching issue when loading in a secondary/background tab


(Core :: Graphics, defect, P3)




Tracking Status
firefox-esr68 --- wontfix
firefox-esr78 --- wontfix
firefox78 --- wontfix
firefox79 --- wontfix
firefox80 --- wontfix
firefox81 --- wontfix
firefox82 --- fix-optional


(Reporter: cfogel, Unassigned)


(Regression, )


(Keywords: correctness, regression)


(1 file)

Attached image badhome.gif

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;
  1. Launch Firefox;
  2. Open a tab, access any random web-page of choice;
  3. With that page in focus, drag the link to so it would open in the background in a second tab;
  4. Wait until the page would load;
  5. 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).

@ :sotaro mind confirming if the regressor is accurate?

Has Regression Range: --- → yes
Has STR: --- → yes
Flags: needinfo?(sotaro.ikeda.g)

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.


But the problem could not be reproduce reliably even with the STR.

Flags: needinfo?(sotaro.ikeda.g)
No longer regressed by: 1603676

I saw the problem even with the following command.

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.

The severity field is not set for this bug.
:ktaeleman, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(ktaeleman)
Component: Graphics: WebRender → Networking: Cache
Flags: needinfo?(ktaeleman)

I think this should not be a networking issue.
Move this to DOM to see why the page is loaded but not rendered.

Component: Networking: Cache → DOM: Core & HTML
No longer blocks: wr-correctness

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.

Component: DOM: Core & HTML → Layout

This is in fact a graphics issue, specially if it only happens with WR. I don't know why it was moved? Kris?

Flags: needinfo?(ktaeleman)

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
mozregression --launch 2020-08-25 --pref gfx.webrender.force-disabled:true -a

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

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:

Disabling tab warming does not help:
mozregression --launch 2020-08-25 --pref gfx.webrender.force-disabled:true browser.tabs.remote.warmup.enabled:false -a

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

Last good seems correct:
mozregression --launch 2018-03-12 --pref gfx.webrender.force-disabled:true -a

Disabling tab warming does not help:
mozregression --launch 2020-08-25 --pref gfx.webrender.force-disabled:true browser.tabs.remote.warmup.enabled:false -a

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

64c633802d4cd0e2c32a271a2d29107b5b43f38 Mike Conley — Bug 1423220 - Enable tab warming by default for Nightly builds. r=dao

Regressed by: 1423220

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.

Blocks: gfx-triage
Component: Layout → Graphics
Flags: needinfo?(ktaeleman)
No longer blocks: gfx-triage
Severity: -- → S3
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.