1625571 - Firefox background images vanish in out-of-focus browser tabs returning to focus

Status: VERIFIED FIXED

(Core :: Layout: Images, Video, and HTML Frames, defect, P2)

Description

[Sylk]

Attachment: Showing 2 screenshots (issue and work-a-round applied)

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:74.0) Gecko/20100101 Firefox/74.0

Steps to reproduce:

1. Load page with background graphic
2. Change to other open browser tabs for a few minutes or more
3. Return to the tab with the background graphic

Actual results:

Notice that sometimes (frequently after longer visits to parallel tabs), the background image will not be showing any more in the tab. All the rest of the content still shows. Hitting refresh will again show the background image.

Expected results:

I would expect the background image to always load with page content when returning to a tab.

Comment 1

[Alice0775 White]

I can reproduce on Nightly76.0a1(20200327094805) Windows10.

Comment 2

[Timothy Nikkel (:tnikkel)]

Hmm, all I need to reproduce is
<style>
body {
background: url("http://covid19responseteam.org/images/background_4_virus.png") no-repeat top center fixed;
background-size: contain;
background-position: center 108px;
}
</style>
and then goto about:memory in a new tab and click minimize memory and then return to the tab. The invalidate for the redecode of the image is getting lost maybe?

Comment 3

[Sylk]

Reducing the size of my background image from 1.24MB to 900KB did not help. Having 5 tabs open to pages from my site that all leverage the background will randomly have various pages missing the background when I revisit the tab.

I also applied a background color of black to show if the background image is not available:

body {
margin: 0;
font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, "Noto Sans", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji";
font-size: .875rem;
font-weight: 400;
line-height: 1.5;
color: #23282c;
text-align: left;
background-color: #000000;
background: url("../images/background_4_virus.png") no-repeat top center fixed;
-webkit-background-size: contain;
-moz-background-size: contain;
-o-background-size: contain;
background-size: contain;
background-position: center 108px;
}

When this issue reproduces, the black color doesn't appear. This suggests that there is no issue fetching the background image (else, the black background-color would show).

Comment 4

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e84157c7ee828bbca6c62ad836aaca28161dab95&tochange=95fe1470b3718d04e5c45605faedda62da140071

Comment 5

[Emilio Cobos Álvarez (:emilio)]

I got https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=cb54b75cf465d79b29e61a10119c4d3d85ee93f9&tochange=079f4b05ead2a525ecf6a4970b7469398a2117c9 instead, which is a bit more likely.

Comment 6

[Sylk]

So far, I cannot reproduce this on a different computer running Firefox version: 68.6.0esr (32-bit)

Comment 7

[Timothy Nikkel (:tnikkel)]

Hmm, I get different results from both regression ranges here: I reproduce the problem in the 2020-02-08 nightly which is before both regression ranges.

Comment 8

[Timothy Nikkel (:tnikkel)]

I get

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=fa233e2c081b14a5589f65e72769a259e0ad4fad&tochange=e3382fdd4f543e1177ba3b0f080d90905cdeb22f

-> bug 1606628

Perhaps the fact that we stopped cloning the imgRequestProxy in that bug?

Comment 9

[Alice0775 White]

This page is also affected.
https://www.w3schools.com/cssref/tryit.asp?filename=trycss_background-image

Comment 10

[Alice0775 White]

(In reply to Timothy Nikkel (:tnikkel) from comment #8)

I get

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=fa233e2c081b14a5589f65e72769a259e0ad4fad&tochange=e3382fdd4f543e1177ba3b0f080d90905cdeb22f

-> bug 1606628

Perhaps the fact that we stopped cloning the imgRequestProxy in that bug?

I confirmed the regression range if using keyboard(like ctrl+1) to switch tab.

Comment 11

[Timothy Nikkel (:tnikkel)]

Looks like there is no display item data here

https://searchfox.org/mozilla-central/rev/8526066f548af9ec3ebb462ff73c47ccc183f533/layout/style/ImageLoader.cpp#501

and so we don't invalidate.

Comment 12

[Timothy Nikkel (:tnikkel)]

That's because we are looking at the wrong frame, it's a confusion between the canvas frame and the body frame.

Comment 13

[Timothy Nikkel (:tnikkel)]

Not really confusion. The body frame is always associated via DidSetComputedStyle. The canvas frame relies on the display item calling Paint or CreateWebRenderCommands to get associated (this seems like a bug since we could layerize the image and hence not call either of those, but this is not the bug that is happening here). After we switch back to the tab we get two paints in a row. The first paint creates a new background image display item and paint gets called on it and the canvas frame gets associated. The second paint replaces that background image display item (it's destructor de-associates the canvas frame), the new background image display item never gets paint called on it (probably because nothing has actually changed and needs to be repainted), and so the canvas frame ends up dis-associated. And then we get the frame update notification but there is no associated frame that has an associated display item so we think the image is not visible and do nothing.

(Another thing, this setup also only works when retained display lists are turned on, otherwise display items only survive one paint. So bug 1619245 is still broken is one flips the retained display list prefs off.)

Comment 14

[Emilio Cobos Álvarez (:emilio)]

Yeah, I think I'm going to move this bit a bit further down and stop associating images to the canvas frame.

Comment 15

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1625571 - Invalidate canvas background in ImageLoader rather than nsDisplayBackgroundImage. r=tnikkel

This is less error prone and also less code.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/acb3f6f0a64e
Invalidate canvas background in ImageLoader rather than nsDisplayBackgroundImage. r=tnikkel

Comment 17

[Andrei Ciure[:aciure]]

https://hg.mozilla.org/mozilla-central/rev/acb3f6f0a64e

Comment 19

[Cristian Fogel [:cfogel]]

Crosschecking with the website linked on comment 9 and several other websites - 76.0a1 (2020-04-01) on macOS 10.15.3 was unable to replicate the reported issue.

Managed to reproduce using steps from comment 2 on Ubuntu 18.04 with
After an extended navigation round with 76.0b6 on Windows 10, macOS 10.15.3 Ubuntu 18.04 issue was not encountered.

Comment 20

[Hashim]

After a day or so of experimenting with a lot of background images and radial gradients on a local static site of mine, I eventually realised this was a bug with Firefox and not my CSS. I arrived at this thread from here. Am I correct in thinking that this has been fixed in Firefox 76? If so, when is Firefox 76 expected to be released by, and is it possible to get it any earlier?

Thank you.

Comment 21

[Timothy Nikkel (:tnikkel)]

76 is scheduled for may 5. You can download beta or nightly. https://www.mozilla.org/en-US/firefox/channel/desktop/