User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0 Build ID: 20141014134955 Steps to reproduce: 1. Start with an empty page (about:blank, not empty landing page) 2. Resize Browser Window (make it larger) Actual results: The newly drawn screen areas (those not visible before resizing) are not rendered white, but black. Expected results: Background should remain white.

I see the on fx34 win8.1, with clear profile, OMTC off or on, hardware acceleration off or on.

I am running FF34 Win7 x64. The bug also occurs with all addons disabled and hardware acceleration off. It did not occur in version 33 (beta), it came to existence since the upgrade to 34 (beta). OMTC is an unfamiliar term to me.

Reminder: It ONLY occurs with about:blank, not a blank landing page (classic)!

STR: 1) Open about:blank 2) Reduce the browser window 3) Maximize I can't reproduce it in FF35+ so it's probably fixed. But maybe we need to backport the fix in FF34 too.

Milan, radar'ing this... can you ensure we uplift whatever fixed this if possible? :-) Loic, can you use mozregression to figure out when this was fixed on aurora? Keep in mind it may have happened when it was still on Nightly (although that shouldn't be hard to check)

(and confirming considering the number of people who report reproducing this)

I didn't find any regression in FF34 builds (between FF34 and FF35 at the end of August), so it probably regressed when a bugfix has been backported from a next Nightly into FF34.

I tried 34b1, the issue is present.

(In reply to Loic from comment #7) > I didn't find any regression in FF34 builds (between FF34 and FF35 at the > end of August), so it probably regressed when a bugfix has been backported > from a next Nightly into FF34. I'm confused. I wanted to know where in 35 this was fixed (per comment #4). As best I can tell you're saying this worked on 34 when it was still on m-c (nightly), is that right? Did it regress while 34 was aurora?

Could you attach the about:support graphics section when this bug shows? I would expect it could be the same issue as that in bug 1085187.

Adapter Description Intel(R) HD Graphics 3000 Adapter Description (GPU #2) NVIDIA GeForce GT 550M Adapter Drivers igdumd64 igd10umd64 igd10umd64 igdumd32 igd10umd32 igd10umd32 Adapter Drivers (GPU #2) nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um Adapter RAM Unknown Adapter RAM (GPU #2) 2048 ClearType Parameters Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 50 Device ID 0x0116 Device ID (GPU #2) 0x0df6 Direct2D Enabled true DirectWrite Enabled true (6.2.9200.16571) Driver Date 1-29-2014 Driver Date (GPU #2) 9-13-2014 Driver Version 9.17.10.3347 Driver Version (GPU #2) 9.18.13.4411 GPU #2 Active false GPU Accelerated Windows 1/1 Direct3D 11 (OMTC) Subsys ID 17121043 Subsys ID (GPU #2) 17121043 Vendor ID 0x8086 Vendor ID (GPU #2) 0x10de WebGL Renderer Google Inc. -- ANGLE (Intel(R) HD Graphics 3000 Direct3D9Ex vs_3_0 ps_3_0) windowLayerManagerRemote true AzureCanvasBackend direct2d AzureContentBackend direct2d 1.1 AzureFallbackCanvasBackend cairo AzureSkiaAccelerated 0

I'm going to tentatively set the dependency on bug 1085187, and it may very well end up being a duplicate. I expect the fix for bug 1085187 this week, so we should have a nightly build soon that we can use to test this issue.

Important graphic glitch, tracking it.

The bug is still present in firefox 34.0b6 release. WFM on Nightly, please recheck.

(In reply to :Gijs Kruitbosch from comment #9) > (In reply to Loic from comment #7) > > I didn't find any regression in FF34 builds (between FF34 and FF35 at the > > end of August), so it probably regressed when a bugfix has been backported > > from a next Nightly into FF34. > > I'm confused. I wanted to know where in 35 this was fixed (per comment #4). > As best I can tell you're saying this worked on 34 when it was still on m-c > (nightly), is that right? Did it regress while 34 was aurora? Yes, the bug wasn't present when 34 was on Nightly channel (that's why I tested the passage of nightly from 34 to 35). So I guess this bug has been introduced into 34 during Aurora or Beta, probably due to a backport from Nightly 35 or 36. Do you know how to test the beta/aurora repository with mozreg? I know the command --repo but which argument to put?

(In reply to Loic from comment #16) > (In reply to :Gijs Kruitbosch from comment #9) > > (In reply to Loic from comment #7) > > > I didn't find any regression in FF34 builds (between FF34 and FF35 at the > > > end of August), so it probably regressed when a bugfix has been backported > > > from a next Nightly into FF34. > > > > I'm confused. I wanted to know where in 35 this was fixed (per comment #4). > > As best I can tell you're saying this worked on 34 when it was still on m-c > > (nightly), is that right? Did it regress while 34 was aurora? > > Yes, the bug wasn't present when 34 was on Nightly channel (that's why I > tested the passage of nightly from 34 to 35). So I guess this bug has been > introduced into 34 during Aurora or Beta, probably due to a backport from > Nightly 35 or 36. > > Do you know how to test the beta/aurora repository with mozreg? > I know the command --repo but which argument to put? Presumably https://hg.mozilla.org/releases/mozilla-aurora/ (and mozilla-beta instead of mozilla-aurora to get beta). If it was in b1, presumably this happened on aurora?

(In reply to :Gijs Kruitbosch from comment #17) > (In reply to Loic from comment #16) > > (In reply to :Gijs Kruitbosch from comment #9) > > > (In reply to Loic from comment #7) > > > > I didn't find any regression in FF34 builds (between FF34 and FF35 at the > > > > end of August), so it probably regressed when a bugfix has been backported > > > > from a next Nightly into FF34. > > > > > > I'm confused. I wanted to know where in 35 this was fixed (per comment #4). > > > As best I can tell you're saying this worked on 34 when it was still on m-c > > > (nightly), is that right? Did it regress while 34 was aurora? > > > > Yes, the bug wasn't present when 34 was on Nightly channel (that's why I > > tested the passage of nightly from 34 to 35). So I guess this bug has been > > introduced into 34 during Aurora or Beta, probably due to a backport from > > Nightly 35 or 36. > > > > Do you know how to test the beta/aurora repository with mozreg? > > I know the command --repo but which argument to put? > > Presumably https://hg.mozilla.org/releases/mozilla-aurora/ (and mozilla-beta > instead of mozilla-aurora to get beta). If it was in b1, presumably this > happened on aurora? But it said no such option: --repo?

OK I ended up download different builds manually.. anyway, here is the result: good: 10-11 bad: 10-12 https://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=f6ccaf5a4b15&tochange=e96a7a4f3bbe

and apparently it's fixed in 35a.

(In reply to Benjamin Peng from comment #20) > and apparently it's fixed in 35a. OK... so now aurora/devedition/35 is fixed (presumably nightly/36 is, too?) and beta/34 is still broken, is that correct? I wonder if we should try to get bug 1085187 uplifted to 34 then, too - assuming that is what fixed it.

(In reply to :Gijs Kruitbosch from comment #21) > (In reply to Benjamin Peng from comment #20) > > and apparently it's fixed in 35a. > > OK... so now aurora/devedition/35 is fixed (presumably nightly/36 is, too?) > and beta/34 is still broken, is that correct? Yeas, nothing has changed since my comment #4.

It regressed by bug 1062100 probably.

Ugh, this is super messy. Aurora was broken for 2 days, and then it was merge day and it was fixed, and beta was broken. Beta is still broken. Then there's the fact that the regressing bug was half-backed-out-but-not-totally and then the backed out patch was updated, and the new version was relanded with the same commit message. AFAICT the right thing happened for aurora uplift. What I'm wondering now is if nightly ever broke (when it was 35) and how that was fixed, if in any way at all. If whatever made this work on nightly predates the landing of 1062100, then we really need someone to investigate what's actually going on rather than just finding regression ranges.

The 09-25 nightly was broken, so looking for a fix range on nightly right now.

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=39f6aa4ae636&tochange=62e308af0e0d Botond and Roc, this is listed as wontfix for 34 by Ryan - but it was backported for b2g. Any reason not to backport it onto (our last!) beta to fix this there?

(In reply to Loic from comment #11) > Adapter Description Intel(R) HD Graphics 3000 > Adapter Description (GPU #2) NVIDIA GeForce GT 550M > Adapter Drivers igdumd64 igd10umd64 igd10umd64 igdumd32 igd10umd32 igd10umd32 > Adapter Drivers (GPU #2) nvd3dumx,nvwgf2umx,nvwgf2umx > nvd3dum,nvwgf2um,nvwgf2um > Adapter RAM Unknown > Adapter RAM (GPU #2) 2048 > ClearType Parameters Gamma: 2200 Pixel Structure: R ClearType Level: 100 > Enhanced Contrast: 50 > Device ID 0x0116 > Device ID (GPU #2) 0x0df6 > Direct2D Enabled true > DirectWrite Enabled true (6.2.9200.16571) > Driver Date 1-29-2014 > Driver Date (GPU #2) 9-13-2014 > Driver Version 9.17.10.3347 > Driver Version (GPU #2) 9.18.13.4411 > GPU #2 Active false > GPU Accelerated Windows 1/1 Direct3D 11 (OMTC) > Subsys ID 17121043 > Subsys ID (GPU #2) 17121043 > Vendor ID 0x8086 > Vendor ID (GPU #2) 0x10de > WebGL Renderer Google Inc. -- ANGLE (Intel(R) HD Graphics 3000 Direct3D9Ex > vs_3_0 ps_3_0) > windowLayerManagerRemote true > AzureCanvasBackend direct2d > AzureContentBackend direct2d 1.1 > AzureFallbackCanvasBackend cairo > AzureSkiaAccelerated 0 While it seems you're using the 550M for display, is the built-in Intel VGA driver also up to date? Wondering if although primary display is being used, it's querying both VGA and doing something odd with the secondary VGA. Also, NVidia 344.65 WHQL were released yesterday.

(In reply to :Gijs Kruitbosch from comment #27) > https://hg.mozilla.org/integration/mozilla-inbound/ > pushloghtml?fromchange=39f6aa4ae636&tochange=62e308af0e0d > > Botond and Roc, this is listed as wontfix for 34 by Ryan - but it was > backported for b2g. Any reason not to backport it onto (our last!) beta to > fix this there? No. Approval requested in bug 1068961.

Bug 1068961 has been uplifted. Any reason not to resolve this bug?

Nope! Thanks, Lawrence.

It's still visible in the latest Beta, I guess it will fixed in the next one, no?

(In reply to Loic from comment #32) > It's still visible in the latest Beta, I guess it will fixed in the next > one, no? Yes, but it's landed on beta already, and I think go to build is today, so this should be on an update server near you "soon".

I was able to reproduce this issue on Firefox 34 Beta 8 using Windows 7 x64, Ubuntu 12.04 x32 and Mac OSX 10.9.5. Verified fixed on Firefox 34 Beta 9 (20141113192814), Latest Aurora 35.0a1 (2014-11-14) and Latest Nightly 36.0a1 (2014-11-14) using Windows 7 x64, Ubuntu 12.04 x32 and Mac OSX 10.9.5.