1124051 - Background image doesn't repeat for the entire page

Status: VERIFIED FIXED

(Core :: Web Painting, defect)

Description

[Gingerbread Man]

Attachment: datauri_thisshouldwork.htm

Steps to reproduce:
1. Open http://15nowtacoma.info/extras/background_display.html

Actual result:
The background image only covers part of the page, near the top.
In Firefox 38.0a1 2014-01-20, there's a solid white color in the part where the image is missing.
In Firefox 35 and Seamonkey 2.32, there's a solid black color in the part where the image is missing.

Expected result:
The background image should cover the entire page, without any gaps of solid color.

Notes:
* If I change the src attribute of the img into a data URI, then it seems to always fill the entire page.
* http://forums.mozillazine.org/viewtopic.php?f=38&t=2907155


Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:38.0) Gecko/20100101 Firefox/38.0
Built from https://hg.mozilla.org/mozilla-central/rev/93f526d85b47

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0
Built from https://hg.mozilla.org/releases/mozilla-release/rev/32e36869f84a

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32
Built from http://hg.mozilla.org/releases/mozilla-release/rev/b2c4309cea44

Comment 1

[Gingerbread Man]

Attachment: Firefox38a1_e10s_enabled.png

Comment 2

[Gingerbread Man]

Attachment: Firefox38a1_e10s_disabled.png

Comment 3

[Gingerbread Man]

Attachment: Firefox35.png

Comment 4

[Gingerbread Man]

Attachment: Seamonkey232.png

Comment 5

[Boris Zbarsky [:bzbarsky]]

I see the issue in Firefox 35, but not in a nightly, Aurora, or beta build...

Comment 6

[Gingerbread Man]

I tested in a brand new profile each time. E10s normally gets disabled for me due to having an IME, so when I had to test with e10s enabled, I set browser.tabs.remote.autostart to true and browser.tabs.remote.autostart.1 to false. It was an otherwise untouched profile.
Here's my about:support Graphics section, in case it's relevant.

Graphics
--------

Adapter Description: NVIDIA GeForce 210
Adapter Drivers: nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um
Adapter RAM: 128
Device ID: 0x0a65
Direct2D Enabled: true
DirectWrite Enabled: true (6.2.9200.16571)
Driver Date: 7-2-2014
Driver Version: 9.18.13.4052
GPU #2 Active: false
GPU Accelerated Windows: 1/1 Direct3D 11 (OMTC)
Subsys ID: 34ee1458
Vendor ID: 0x10de
WebGL Renderer: Google Inc. -- ANGLE (NVIDIA GeForce 210 Direct3D11 vs_4_1 ps_4_1)
windowLayerManagerRemote: true
AzureCanvasBackend: direct2d 1.1
AzureContentBackend: direct2d 1.1
AzureFallbackCanvasBackend: cairo
AzureSkiaAccelerated: 0

Comment 7

[Boris Zbarsky [:bzbarsky]]

Yeah, in case it's relevant, I'm on Mac.

roc, this seems likely to be a display list or layers issue...

Comment 8

[Alice0775 White]

Reproduced with/without e10s.

#1 regression:  Black rectangle appears bottom/bottom-left
#2 regression:  White rectangle appears Bottom/Bottom-right

STR
1. Clear cache and restart
2. Open URL


#1Regression window(m-c)
Good:
https://hg.mozilla.org/mozilla-central/rev/43ab820c7b68
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0 ID:20140926183438
Bad (Black rectangle appears):
https://hg.mozilla.org/mozilla-central/rev/818f353b7aa6
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0 ID:20140926185339
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=43ab820c7b68&tochange=818f353b7aa6

Regressed by:
818f353b7aa6	Seth Fowler — Bug 1069369 - Remove all manual discarding during frame lookup. r=tn a=kwierso

#2Regression window
Bad (Black rectangle appears):
https://hg.mozilla.org/integration/mozilla-inbound/rev/bd3c5d90a40c
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0 ID:20141210192813
Bad (white rectangle appears instead of black):
https://hg.mozilla.org/integration/mozilla-inbound/rev/a5fcba591258
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0 ID:20141210193712
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=bd3c5d90a40c&tochange=a5fcba591258

Regressed by:
a5fcba591258	Seth Fowler — Bug 1098958 - Call UpdateImageContainer whenever we send invalidations in RasterImage. r=tn

Comment 9

[Seth Fowler [:seth] [:s2h]]

Hmm. Do we use ImageContainers for CSS background images?

Comment 10

[Alice0775 White]

Oddly, but fortunately, I cannot reproduce Firefox36.0b2.
It has been completely fixed in 36 by bug 1098958.
There are another factor something in 37 and 38.

Fixed range
Bad (black rectangle)
https://hg.mozilla.org/releases/mozilla-aurora/rev/856e6399952a
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0 ID:20141215061737
Fixed
https://hg.mozilla.org/releases/mozilla-aurora/rev/6f4775cbadf1
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0 ID:20141215090739
Pushlog:
https://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=856e6399952a&tochange=6f4775cbadf1

Comment 11

[Boris Zbarsky [:bzbarsky]]

> Hmm. Do we use ImageContainers for CSS background images?

We use imgIRequest, which presumably then uses whatever it does under the hood, right?  Or did you mean for the painting specifically?

Comment 12

[Seth Fowler [:seth] [:s2h]]

(In reply to Boris Zbarsky [:bz] from comment #11)
> > Hmm. Do we use ImageContainers for CSS background images?
> 
> We use imgIRequest, which presumably then uses whatever it does under the
> hood, right?  Or did you mean for the painting specifically?

I meant layers::ImageContainer, not image::imgIContainer. =) It's not great that those names are so similar.

My mental model is that we only use ImageContainer for layerized images, and that we do not layerize CSS background images. That's why it's surprising to me that bug 1098958 has any effect here. Since it did, I must be wrong about one of those two things!

Comment 13

[Matt Woodrow (:mattwoodrow)]

(In reply to Seth Fowler [:seth] from comment #9)
> Hmm. Do we use ImageContainers for CSS background images?

Yes, we can do.

Display items that inherit from nsDisplayImageContainer can potentially be optimized into an ImageLayer and render using an ImageContainer.

Comment 14

[Seth Fowler [:seth] [:s2h]]

Thanks, Matt!

So after looking at the test case, it now makes more sense to me that we're layerizing this image. I expected from the bug description that this involved CSS backgrounds, but it *doesn't*. The image in the test case is actually an <img> element with 'position: fixed' set. Other content (if there were any; the "wrapper" div is empty) is then placed above it by wrapping it in a div with 'position: relative' and 'z-index: 1'. This technique is used to try to get the same effect as 'background-attachment: fixed' would give, as far as I can tell.

I cannot reproduce locally on OS X; I'll try in a Linux VM.

Comment 15

[Lawrence Mandel [:lmandel] (use needinfo)]

seth - Looks like you're working on this. Can I assign the bug to you?

Comment 16

[Seth Fowler [:seth] [:s2h]]

I can't reproduce on OS X or Windows or Linux with Nightly, and it seems that while a patch of mine did introduce an issue on this page in 35, a subsequent patch of mine fixed that in 36.

So right now we have no regression range for the reported issue in Nightly, and we can't reproduce. Until at least one of those two things changes, I don't see any progress getting made on this bug. It shouldn't be assigned to anyone at this point.

Comment 17

[Alice0775 White]

I can reproduce the problem in latest Nightly38.0a1 and Aurora37.0a2

https://hg.mozilla.org/mozilla-central/rev/38e4719e71af
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0 ID:20150127030230

https://hg.mozilla.org/releases/mozilla-aurora/rev/8f49a2fc3f0c
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0 ID:20150127004030

Comment 18

[Seth Fowler [:seth] [:s2h]]

Excellent! I think two things might help here:

- Could you post your graphics info from about:support? Hopefully that will help us figure out why some people can reproduce this and some can't.

- I know it's a lot to ask, but could you try to find the regression range in 37, since it sounds like a different commit broke this again there?

Comment 19

[Alice0775 White]

(In reply to Seth Fowler [:seth] from comment #18)
> Excellent! I think two things might help here:
> 
> - Could you post your graphics info from about:support? Hopefully that will
> help us figure out why some people can reproduce this and some can't.
> 

Reproduced on windows7

Graphics
--------

Adapter Description: AMD Radeon HD 6450
Adapter Drivers: aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64
Adapter RAM: 1024
ClearType Parameters: Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 200
Device ID: 0x6779
Direct2D Enabled: true
DirectWrite Enabled: true (6.2.9200.16571)
Driver Date: 11-20-2014
Driver Version: 14.501.1003.0
GPU #2 Active: false
GPU Accelerated Windows: 1/1 Direct3D 11 (OMTC)
Subsys ID: 23111787
Vendor ID: 0x1002
WebGL Renderer: Google Inc. -- ANGLE (AMD Radeon HD 6450 Direct3D11 vs_5_0 ps_5_0)
windowLayerManagerRemote: true
AzureCanvasBackend: direct2d 1.1
AzureContentBackend: direct2d 1.1
AzureFallbackCanvasBackend: cairo
AzureSkiaAccelerated: 0


Reproduced on Ubuntu14.04 32bit

Graphics
--------

Adapter Description: VMware, Inc. -- Gallium 0.4 on SVGA3D; build: RELEASE;
Device ID: Gallium 0.4 on SVGA3D; build: RELEASE;
Driver Version: 2.1 Mesa 10.1.3
GPU Accelerated Windows: 0/1 Basic (OMTC)
Vendor ID: VMware, Inc.
WebGL Renderer: VMware, Inc. -- Gallium 0.4 on SVGA3D; build: RELEASE;
windowLayerManagerRemote: true
AzureCanvasBackend: cairo
AzureContentBackend: cairo
AzureFallbackCanvasBackend: none
AzureSkiaAccelerated: 0

> 
> - I know it's a lot to ask, but could you try to find the regression range
> in 37, since it sounds like a different commit broke this again there?

It is difficult to find the commit without special build, because Bug 1098958 is hiding it.

Comment 20

[Alice0775 White]

Attachment: Bug1124051.zip

I think it is depended on network speed.

I setup VMWare player and Limit the network speed like 192kbps.
Then, I can reproduce in local.

However, when I set up 1.5Mbps, I cannot reproduce.

Steps
1. Setup local http server
2. Limit the network speed like 192kbps
3. Open index2.html

Comment 21

[Alice0775 White]

And I found a WORKAROUND

set new integer prefs nglayout.initialpaint.delay = 10000 in about:config (Restart required)

Comment 22

[Seth Fowler [:seth] [:s2h]]

(In reply to Alice0775 White from comment #20)
> I think it is depended on network speed.

Very interesting! This might help me reproduce the issue. Thanks!

(In reply to Alice0775 White from comment #21)
> And I found a WORKAROUND
> 
> set new integer prefs nglayout.initialpaint.delay = 10000 in about:config
> (Restart required)

That strongly suggests an invalidation problem.

Comment 23

[Seth Fowler [:seth] [:s2h]]

This should be fixed by bug 1130328, which we are still hoping to get into 36.

Comment 24

[wtimbr]

I'm experiencing something that seems related to issue above in FF 35.0.1.

When using Jquery Backstretch the second en next images that are loaded dynamically look pixelated.
Topic here: https://github.com/srobbin/jquery-backstretch/issues/403#issuecomment-74027840

dynamic loaded html looks like:
<div class="backstretch" style="left: 0px; top: 0px; overflow: hidden; margin: 0px; padding: 0px; height: 694px; width: 1903px; z-index: -999999; position: fixed;">
  <img style="position: absolute; margin: 0px; padding: 0px; border: medium none; width: 1903px; height: 1070.44px; max-height: none; max-width: none; z-index: -999999; left: 0px; top: -188.219px;" src="/images/background.jpg">
</div>

Fingers are pointing at FireFox, other browsers seem to have no issue

Comment 25

[Emanuel Hoogeveen [:ehoogeveen]]

The description of your problem sounds more like bug 1125077 to me, which may have been fixed by bug 1098958 (which should be in Firefox 36).

Comment 26

[Gingerbread Man]

Nightly x64 38.0a1 2015-02-13
Built from https://hg.mozilla.org/mozilla-central/rev/2f5c5ec1a24b

I can now see the background being filled in diagonally, from the top left to the bottom right. That seems strange, though I guess it does resolve the issue of missing pieces of the background. Is that how the fix in bug 1130328 is supposed to work? If yes, then I suppose this report should be marked as a duplicate of that one.

Comment 27

[Lawrence Mandel [:lmandel] (use needinfo)]

Seth:

1. Bug 1130328 has been uplifted to 36 and 37. Can this be resolved?
2. Can you answer the question in comment 26 about how the fix is supposed to work?

Comment 28

[Lawrence Mandel [:lmandel] (use needinfo)]

Seth - Assigning to you as you fixed bug 1130328 and have been driving this bug as well.

Comment 29

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

Verified fixed on Firefox 36, 37 and 38 as part of verification for bug 1130328. 

Leaving the needinfo in case it needs a follow up bug.

Comment 30

[Seth Fowler [:seth] [:s2h]]

(In reply to Gingerbread Man from comment #26)
> Nightly x64 38.0a1 2015-02-13
> Built from https://hg.mozilla.org/mozilla-central/rev/2f5c5ec1a24b
> 
> I can now see the background being filled in diagonally, from the top left
> to the bottom right. That seems strange, though I guess it does resolve the
> issue of missing pieces of the background. Is that how the fix in bug
> 1130328 is supposed to work? If yes, then I suppose this report should be
> marked as a duplicate of that one.

Yes, that's precisely what's expected, because the "background" in this test case is an <img> element, and we decode <img> elements progressively.

Comment 31

[Seth Fowler [:seth] [:s2h]]

(In reply to Florin Mezei, QA (:FlorinMezei) from comment #29)
> Verified fixed on Firefox 36, 37 and 38 as part of verification for bug
> 1130328. 
> 
> Leaving the needinfo in case it needs a follow up bug.

Sorry for replying so slowly. There's no need for a followup. This is fixed completely.