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.

Can you provide the graphics section of about:support ?

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

(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

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...

(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.

(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.

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

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.

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.

(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... :-)

(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

(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.

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

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/

(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?

(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.

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.

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

Tracking per comment 5.

(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?

(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.

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

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 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 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 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.

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).