STR: 1) Create a new profile, enable HWA. 2) Open a gmail tab and define a background image for gmail (a predefined or an uploaded one - it seems like the bigger the image, the more perceivable the issue, so if possible upload a hi-res image) 3) open another tab and stay there for a while (30s-1minute) 4) switch back to the gmail tab ER: The background image should appear fully as soon as you switch back to the gmail tab. AR: The background image is not displayed (solid dark grey background instead), or is displayed partially and gets painted gradually as time passes. Hovering/clicking the mouse over still un-painted zones seems to force a repaint that allows you to see the full image faster. Also hovering the mouse over the chat widget or gmail label tree on the left seems to trigger some repaint event. Additional info: last working build is http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012-06-27-03-05-27-mozilla-central/ first broken build is http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012-06-28-01-05-52-mozilla-central/ My Intel GPU is blacklisted (by both builds though, so this shouldn't be a difference)

PS: just to avoid confusion for the description to the second attachment ("though still not all of them"). If you wait some more time the image finally becomes FULLY visible.

Range mentioned in Comment 0: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5cdbeae14405&tochange=bf8f2961d0cc

Regression window Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/06e7df3a8209 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120627083614 Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/7ef9568fbd40 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120627084814 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=06e7df3a8209&tochange=7ef9568fbd40 Suspected: Bug 758620

The patch of bug 769541 seems to fix this problem.

I confirm comment 8, tested with try build: ftp://ftp.mozilla.org/pub/firefox/try-builds/chrislord.net@gmail.com-b9cad627572c

Seems like it happens with HWA disabled too, starting from yesterday's build (http://hg.mozilla.org/mozilla-central/rev/a26e751bfb54)

Can someone confirm this is fixed on Aurora now that bug 769541 has landed there? If so, we can dupe this bug.

I cannot reproduce anymore in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120808042008

I can't reproduce it anymore with Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20120811 Firefox/16.0

This bug has been temporarily fixed for several days, but comes back in the recent nightly. Both 17.0a1 nightly 20120812 and 20120813 can reproduce it.

(In reply to JC Yang from comment #14) > This bug has been temporarily fixed for several days, but comes back in the > recent nightly. Both 17.0a1 nightly 20120812 and 20120813 can reproduce it. Seems like this was fixed after the landing of bug 769541 but it's come back. Can someone please confirm? Is this a different bug with the same symptom?

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #15) > Seems like this was fixed after the landing of bug 769541 but it's come > back. Can someone please confirm? Is this a different bug with the same > symptom? Clarification, please see if this reproduces with the latest Nightly and latest Aurora. Thanks.

Just now, I test again with a new profile in the latest nightly(8-29, built from http://hg.mozilla.org/mozilla-central/rev/418955e7c3a9), it still can be reproduced.

Thanks JC Yang. Can you please test to see when this bug went away and when it came back, or if it ever did for you? Testing with the Aurora build from 2012-07-27 should confirm if the fix for bug 769541 worked for you. If it is not reproducible in that build then that means we shipped a regression in Nightly between 2012-07-27 and today which caused this bug to come back. In which case I need you to try to find when that happened. The mozregression tool can help track this down: http://harthur.github.com/mozregression/ Thanks in advance for your help.

(In reply to JC Yang from comment #17) > Just now, I test again with a new profile in the latest nightly(8-29, built > from http://hg.mozilla.org/mozilla-central/rev/418955e7c3a9), it still can > be reproduced. I'm unable to reproduce it with http://hg.mozilla.org/mozilla-central/rev/418955e7c3a9 Are you following the same STR? How long do you keep the gmail tab unfocused for the issue to appear? Also, unfortunately I'll have to give back my workstation tomorrow, and my personal notebook has a very old (and blacklisted) GMA X3100, so I won't be of any help anymore.

Andrea, I'm sorry that I might mistake some important facts. My GPU is nvidia 6150SE, it's D3D9 acceleration is blocked. But this is still pretty weird, isn't it? If the card was blocked, how the hell can this bug triggered? I haven't check about:support to confirm the HWA state in the past, so I'm not sure whether this is another bug about not successfully block certain cards/drivers. And one more strange thing is, I can't reproduce with today's nightly, date 8-30. Just check about:support, it indeed indicate my driver(not my card, huh?) is blocked. From the information here, https://wiki.mozilla.org/Blocklisting/Blocked_Graphics_Drivers. It is my card to be blocked, rather than my driver. My driver version is 6.14.11.8634, which is perfectly valid in XP. Anyway, it's ok to confirm it now. I'll post more new find if I can.

Hi JC, actually to me too it seems pretty weird that it gets triggered with a blacklisted GPU, since this fact should prevent HWA to be active (AFAIK). Does the issue still occur if you disable HWA from the Fx preferences (this should certainly disable HWA no matter if your GPU driver is blacklisted or not).

After carefully isolate factors may affect, here are 3 definite results of latest Nightly: 1. From my XP SP3 machine with Nvidia 6150SE(blocked), new profile, HWA enabled in UI setting(confirmed blocked from about:support), this bug is not reproducible. 2. From my XP SP3 machine with Nvidia 6150SE(blocked), new profile, HWA disabled in UI setting, this bug is not reproducible. 3. From my Win7 x64 SP1 machine with Nvidia Geforce 210 and valid driver(296.10), new profile, HWA enabled(confirmed work from about:support), this bug is not reproducible. So I think at least the latest Nightly are no longer buggy.

JC Yang, thanks. Would you be able to use http://harthur.github.com/mozregression/ to track down when this got "fixed" on Nightly for you? This would help us isolate a patch which we might be able to uplift to Aurora/Beta to get it fixed sooner. Otherwise people will need to wait for Firefox 18 to release.

Anthony, I'd like to help when I'm free. I'll report it when the finding is done.

I have the exact same symptoms on linux with aurora.

(In reply to Mike Hommey [:glandium] from comment #25) > I have the exact same symptoms on linux with aurora. Can you verify if Beta 16 is affected and Nightly 18 is fixed?

(In reply to Alex Keybl [:akeybl] from comment #26) > (In reply to Mike Hommey [:glandium] from comment #25) > > I have the exact same symptoms on linux with aurora. > > Can you verify if Beta 16 is affected and Nightly 18 is fixed? It doesn't seem 16b2 is affected, and it does seem nightly 18 is fixed. That is, in both cases, i do see a gray background instead of the image, but the image does show up in its entirety, instead of in random pieces.

@Mike: How long do you have to wait for the image to show up? Because although I'm no longer experiencing the piece-wise painting, there's still a transition from grey, but it's barely perceivable, and I think it's related to some other cause. In fact the issue you are describing can be reproduced also with HWA DISABLED (which is my current configuration), so maybe we should file a different bug should be filed for that, something like "gmail background painted after delay when coming back from another tab". This delay does not occur with chromium, so I think it's definitely a bug (a different one, though) @JC Yang: in which description does your issue fit best? Are you experiencing piece-wise painting (as described in the "AR" section of the bug report), or full image painting with a slight delay, like Mike? (In reply to Mike Hommey [:glandium] from comment #27) > (In reply to Alex Keybl [:akeybl] from comment #26) > > (In reply to Mike Hommey [:glandium] from comment #25) > > > I have the exact same symptoms on linux with aurora. > > > > Can you verify if Beta 16 is affected and Nightly 18 is fixed? > > It doesn't seem 16b2 is affected, and it does seem nightly 18 is fixed. That > is, in both cases, i do see a gray background instead of the image, but the > image does show up in its entirety, instead of in random pieces.

(In reply to Andrea from comment #28) > @Mike: How long do you have to wait for the image to show up? Because > although I'm no longer experiencing the piece-wise painting, there's still a > transition from grey, but it's barely perceivable, and I think it's related > to some other cause. > In fact the issue you are describing can be reproduced also with HWA > DISABLED (which is my current configuration), so maybe we should file a > different bug should be filed for that, something like "gmail background > painted after delay when coming back from another tab". This delay does not > occur with chromium, so I think it's definitely a bug (a different one, > though) Yeah, that would be a different bug, and afaik, this is a deliberate "feature": we throw away decoded images on inactive tabs and windows, and for big images like gmail background, redecoding the image can take some time. This feature is much older than the issue of painting in pieces.

(In reply to Mike Hommey [:glandium] from comment #29) > (In reply to Andrea from comment #28) > > @Mike: How long do you have to wait for the image to show up? Because > > although I'm no longer experiencing the piece-wise painting, there's still a > > transition from grey, but it's barely perceivable, and I think it's related > > to some other cause. > > In fact the issue you are describing can be reproduced also with HWA > > DISABLED (which is my current configuration), so maybe we should file a > > different bug should be filed for that, something like "gmail background > > painted after delay when coming back from another tab". This delay does not > > occur with chromium, so I think it's definitely a bug (a different one, > > though) > > Yeah, that would be a different bug, and afaik, this is a deliberate > "feature": we throw away decoded images on inactive tabs and windows, and > for big images like gmail background, redecoding the image can take some > time. This feature is much older than the issue of painting in pieces. Thanks Mike, after some research I found bug 676270. Setting the image.mem.max_ms_before_yield preference to 400ms instead of 5 is an effective workaround for me (see comment 3 on that bug).

(In reply to Mike Hommey [:glandium] from comment #27) > It doesn't seem 16b2 is affected, and it does seem nightly 18 is fixed. That > is, in both cases, i do see a gray background instead of the image, but the > image does show up in its entirety, instead of in random pieces. Thanks glandium - untracking for FF16 in that case.

Chris, as the assignee of bug 769541, can you look into what might be causing this to show up in Aurora only?

Is Aurora still affected, now that bug 785333 has landed there?

(In reply to Karl Tomlinson (:karlt) from comment #33) > Is Aurora still affected, now that bug 785333 has landed there? Now that you mention it, i haven't seen the problem for a while now.

This should not be resolved fixed. QA - can you confirm?

now*

I've asked Jason Smith to take a look at this in our QA lab. He'll report back with his results momentarily.

I don't have enough information to understand what's being tested here. HWA is enabled how?

(In reply to Jason Smith [:jsmith] from comment #38) > I don't have enough information to understand what's being tested here. HWA > is enabled how? Got my answer. Let me look quickly.

Looks good on Nightly. Got it to reproduce with the first bad built in comment 0 with the reduced test case with an ATI Radeon HD 4200 Graphics Card. On the latest nightly, I didn't see this reproduce at all.

Thanks Jason. Could you please also check against 17.0b2 and latest-18.0a2 on Monday?

This still needs to be verified. Setting the qacontact to Jason.

Looks good on Beta 4, latest Aurora, and latest nightly.