Closed Bug 1086985 Opened 10 years ago Closed 10 years ago

Portions of screen turn Black on Resizing empty page (about:blank)

Categories

(Core :: Graphics, defect)

34 Branch
x86_64
Windows 7
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla35
Tracking Status
firefox33 --- unaffected
firefox34 + verified
firefox35 + verified
firefox36 + verified

People

(Reporter: julius.reich, Assigned: botond)

References

Details

(Keywords: regression)

Attachments

(1 file)

Attached image blank.jpg
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.
Product: Firefox → Core
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.
Component: Untriaged → Graphics
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)
Flags: needinfo?(milan)
Flags: needinfo?(epinal99-bugzilla2)
(and confirming considering the number of people who report reproducing this)
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Flags: needinfo?(epinal99-bugzilla2)
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?
Flags: needinfo?(epinal99-bugzilla2)
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.
Flags: needinfo?(milan)
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.
Depends on: 1085187
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?
Flags: needinfo?(epinal99-bugzilla2)
(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.
Flags: needinfo?(human.peng)
Flags: needinfo?(epinal99-bugzilla2)
(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.
Flags: needinfo?(epinal99-bugzilla2)
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.
Blocks: 1062100
Flags: needinfo?(human.peng)
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?
Depends on: 1068961
No longer depends on: 1085187
Flags: needinfo?(roc)
Flags: needinfo?(botond)
(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.
Flags: needinfo?(roc)
Flags: needinfo?(botond)
Nope! Thanks, Lawrence.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
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".
Assignee: nobody → botond
Target Milestone: --- → mozilla35
Flags: qe-verify+
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.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: