1040187 - A nightly GUI bug that causes the add tab button image to 'stick' on the tab bar

Status: VERIFIED FIXED

(Core :: Graphics, defect)

Description

[mainboard71]

Attachment: an image of the bug

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 (Beta/Release)
Build ID: 20140605174243

Steps to reproduce:

opened a new tab then closed it in the most recent Nightly 64 bit version


Actual results:

the add tab button seems to 'stick' where it was on the second tab.


Expected results:

it should not stick there as it does in the screenshot.

Comment 1

[:Gijs (he/him)]

Can you provide the graphics section of about:support ?

Comment 3

[:Gijs (he/him)]

pypcier, can you provide the graphics portion of about:support  (Help > Troubleshooting information) ?

Comment 4

[pypcier]

(In reply to :Gijs Kruitbosch (Gone July 26 - August 3) from comment #3)
> pypcier, can you provide the graphics portion of about:support  (Help >
> Troubleshooting information) ?

Graphics
--------

Adapter Description: ATI Radeon HD 4300/4500 Series
Adapter Drivers: aticfx32 aticfx32 atiumdag atidxx32 atiumdva
Adapter RAM: 512
ClearType Parameters: Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 100
Device ID: 0x954f
Direct2D Enabled: Blocked for your graphics driver version.
DirectWrite Enabled: false (6.2.9200.16581)
Driver Date: 4-24-2013
Driver Version: 8.970.100.0
GPU #2 Active: false
GPU Accelerated Windows: 1/1 Direct3D 11 (OMTC)
Vendor ID: 0x1002
WebGL Renderer: Google Inc. -- ANGLE (ATI Radeon HD 4300/4500 Series Direct3D9Ex vs_3_0 ps_3_0)
windowLayerManagerRemote: true
AzureCanvasBackend: skia
AzureContentBackend: cairo
AzureFallbackCanvasBackend: cairo
AzureSkiaAccelerated: 0

Comment 5

[:Gijs (he/him)]

Milan, this looks like a recent graphics regression... can you have a look? Note in particular that bug 1043348 comment #0 (from the dupe) noted that this goes away in safe mode, but not when disabling add-ons, which means I suspect this is fixed by turning off hardware accelerated rendering...

Comment 6

[pypcier]

(In reply to :Gijs Kruitbosch (Gone July 26 - August 3) from comment #5)
> Milan, this looks like a recent graphics regression... can you have a look?
> Note in particular that bug 1043348 comment #0 (from the dupe) noted that
> this goes away in safe mode, but not when disabling add-ons, which means I
> suspect this is fixed by turning off hardware accelerated rendering...

You are right, disabling hardware acceleration in settings fixed this issue for me.

Comment 7

[:Gijs (he/him)]

(In reply to pypcier from comment #6)
> (In reply to :Gijs Kruitbosch (Gone July 26 - August 3) from comment #5)
> > Milan, this looks like a recent graphics regression... can you have a look?
> > Note in particular that bug 1043348 comment #0 (from the dupe) noted that
> > this goes away in safe mode, but not when disabling add-ons, which means I
> > suspect this is fixed by turning off hardware accelerated rendering...
> 
> You are right, disabling hardware acceleration in settings fixed this issue
> for me.

Thanks for the confirmation! Do you think you would be comfortable trying to look for a regression window on recent nightly, ie figuring out when this broke? If you know it happened recently, you could look manually, but we also have an automated python tool that can help: http://mozilla.github.io/mozregression/ .

Ideally we'd want to know what dates and/or revisions this last worked and first broke.

Comment 8

[Alice0775 White]

I can reproduce the problem only if I set gfx.direct2d.disabled = false;

Regression window(m-c)
Good:
https://hg.mozilla.org/mozilla-central/rev/cd6457486d15
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 ID:20140709123540
Bad:
https://hg.mozilla.org/mozilla-central/rev/6db315bcdb6a
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 ID:20140709124632
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cd6457486d15&tochange=6db315bcdb6a

Regression window(m-i)
Good:
https://hg.mozilla.org/integration/mozilla-inbound/rev/b37955bdf1b6
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 ID:20140709071430
Bad:
https://hg.mozilla.org/integration/mozilla-inbound/rev/99690880e8f5
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 ID:20140709072429
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=b37955bdf1b6&tochange=99690880e8f5

Triggered by:
	99690880e8f5	Bas Schouten ? Bug 1035227: Upload partial surfaces when an upload region is specified. r=nical

Comment 9

[pypcier]

After trying many Nightly builds It turns out the problem was in fact caused by one of my addons (FireGestures) which is weird because disabling, or even removing it doesn't fix this issue. I feel pretty stupid for wasting your time.

Comment 10

[pypcier]

Disregard my previous comment. I don't have any idea what's causing it but it's back after installing a few addons.
HTTPS-Everywhere 3.5.3
Nightly Tester Tools 3.7
NoScript 2.6.8.33
Self-Destructing Cookies 0.4.4
YouTube ALL HTML5 2.1.3
It looks like it's not caused by one of my addons but rather by installing an addon. I have a lot of free time today so I can test anything you want, just ask.

Comment 11

[:Gijs (he/him)]

(In reply to pypcier from comment #10)
> Disregard my previous comment. I don't have any idea what's causing it but
> it's back after installing a few addons.
> HTTPS-Everywhere 3.5.3
> Nightly Tester Tools 3.7
> NoScript 2.6.8.33
> Self-Destructing Cookies 0.4.4
> YouTube ALL HTML5 2.1.3
> It looks like it's not caused by one of my addons but rather by installing
> an addon. I have a lot of free time today so I can test anything you want,
> just ask.

Per comment 8, I think this is a real regression, and we can use the bug that was found to cause it there to move forward. Not sure what else, if anything, needs testing until/unless we find a fix... :-)

Comment 12

[Alice0775 White]

(In reply to Alice0775 White from comment #8)
> I can reproduce the problem only if I set gfx.direct2d.disabled = false;
> 

Err
gfx.direct2d.disabled = true

Comment 13

[Bas Schouten (:bas.schouten)]

(In reply to Alice0775 White from comment #12)
> (In reply to Alice0775 White from comment #8)
> > I can reproduce the problem only if I set gfx.direct2d.disabled = false;
> > 
> 
> Err
> gfx.direct2d.disabled = true

That makes sense. I'll fix this.

Comment 14

[Bas Schouten (:bas.schouten)]

I cannot reproduce this bug, is this strictly on 64-bit?

Comment 16

[(mostly gone) XtC4UaLL [:xtc4uall]]

As seen per Bug 1054729 this likely affects every already and about-to-be D2D-blocked GPU.
D3D is active then and thus safemode does not expose this.

(In reply to Elbart from Bug 1054729 comment 0)
> STR:
> - Open Nightly
> - Middle-click on the "Get your NIghtly User badge"-link

... on http://www.mozilla.org/en-US/firefox/nightly/firstrun/

Comment 17

[Benjamin Kerensa [:bkerensa]]

(In reply to Bas Schouten (:bas.schouten) from comment #14)
> I cannot reproduce this bug, is this strictly on 64-bit?

Do you have thoughts on tracking?

Comment 18

[Bas Schouten (:bas.schouten)]

(In reply to Benjamin Kerensa [:bkerensa] from comment #17)
> (In reply to Bas Schouten (:bas.schouten) from comment #14)
> > I cannot reproduce this bug, is this strictly on 64-bit?
> 
> Do you have thoughts on tracking?

It's still not clear to be whether this is 64-bit only? I still have never seen this bug.

Comment 19

[(mostly gone) XtC4UaLL [:xtc4uall]]

Easily reproducible with Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0 ID:20140820030202 CSet: ffdd1a398105, i.e. x86 Firefox running on Windows 7 x64 with gfx.direct2d.disabled;true set.

Comment 20

[Elbart]

What do you mean with "64-bit only"? All reports here are from Firefox 32bit ("WOW64").

Comment 21

[Benjamin Kerensa [:bkerensa]]

Tracking per comment 5.

Comment 22

[Bas Schouten (:bas.schouten)]

(In reply to Elbart from comment #20)
> What do you mean with "64-bit only"? All reports here are from Firefox 32bit
> ("WOW64").

The initial report said: 'opened a new tab then closed it in the most recent Nightly 64 bit version'

I'll try to reproduce this again, but now that I know this is easily reproducible for some people, I actually have an idea of what might cause this. XtC4UaLL, could you post your about graphics section? Can you confirm you're on an NVidia card?

Comment 23

[Bas Schouten (:bas.schouten)]

(In reply to Bas Schouten (:bas.schouten) from comment #22)
> (In reply to Elbart from comment #20)
> > What do you mean with "64-bit only"? All reports here are from Firefox 32bit
> > ("WOW64").
> 
> The initial report said: 'opened a new tab then closed it in the most recent
> Nightly 64 bit version'
> 
> I'll try to reproduce this again, but now that I know this is easily
> reproducible for some people, I actually have an idea of what might cause
> this. XtC4UaLL, could you post your about graphics section? Can you confirm
> you're on an NVidia card?

Yes, I've confirmed I -can- reproduce this on an NVidia machine. I'll have a fix up here soon which we will be able to uplift.

Comment 24

[Bas Schouten (:bas.schouten)]

Sadly my initial hunch was incorrect. I'll continue working on debugging this.

Comment 25

[Bas Schouten (:bas.schouten)]

Attachment: Combine update regions when upload hasn't been executed yet

So this turns out to be a tricky timing issue, which is why it's so device/compositor independent. This has everything to do with the compositor not compositing in time, and since we overwrite the previous update region when we receive a new one, a subsequent composition will only upload the new region not the old one.

I've chosen a fairly hacky, but simple approach to fix this, so we can test it and easily uplift with little to no risk.

It's somewhat worrying this bug occurs, since it means when opening and closing tabs our D3D11 compositor is having a particularly hard time. At the same time it's sort of surprising we haven't seen this bug anywhere else!

Comment 26

[Nicolas Silva [:nical]]

Comment on attachment 8478868 [details] [diff] [review]
Combine update regions when upload hasn't been executed yet

Review of attachment 8478868 [details] [diff] [review]:
-----------------------------------------------------------------

Good catch

Comment 27

[Bas Schouten (:bas.schouten)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/57a02fe884d9

Comment 28

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/57a02fe884d9

Comment 29

[Bas Schouten (:bas.schouten)]

Comment on attachment 8478868 [details] [diff] [review]
Combine update regions when upload hasn't been executed yet

Approval Request Comment
[Feature/regressing bug #]: OMTC
[User impact if declined]: Drawing artifacts
[Describe test coverage new/current, TBPL]: Nightly & Aurora
[Risks and why]: -Must- be combined with 1060114. Relatively low risk, extensively tested.
[String/UUID change made/needed]: None

Comment 30

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

Comment on attachment 8478868 [details] [diff] [review]
Combine update regions when upload hasn't been executed yet

beta+. Approval coming for bug 1060114. These changes will ship in beta2.

Comment 31

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/872fe12f9214

Comment 33

[Petruta Horea [:phorea], Desktop QA]

Reproduced with gfx.direct2d.disabled = true using Nightly 33.0a1 2014-07-17.

Verified as fixed using Firefox 33 beta 2 (20140908190852) and latest Aurora 34.0a2 (20140907004002).