User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:33.0) Gecko/20100101 Firefox/33.0 (Beta/Release) Build ID: 20140721030205 Steps to reproduce: on nightly 64-bit build with all plugins disabled: 1. open two tabs, one to youtube.com and one to another place (like bugzilla or google) Actual results: both corners of the tab bar become black witch slowly fade in the middle when youtube.com tab is open Expected results: the tab bar should not be effected by a site

Regression window(m-i) Good: https://hg.mozilla.org/integration/mozilla-inbound/rev/9350909a3401 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 ID:20140719062420 Bad: https://hg.mozilla.org/integration/mozilla-inbound/rev/24a69de91baa Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 ID:20140719065519 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=9350909a3401&tochange=24a69de91baa Regressed by: Bug 1022612

[Tracking Requested - why for this release]:

i was trying to add that firefox 34 has this bug too, but couldnt flag as "affected"

Unfortunately I've had to back out the push that contain this, for turning mochitest-1 orange on debug OS X. Nothing appears in the brief log annoyingly, eg: https://tbpl.mozilla.org/php/getParsedLog.php?id=44517570&tree=Mozilla-Inbound https://tbpl.mozilla.org/php/getParsedLog.php?id=44517238&tree=Mozilla-Inbound And the full log just helpfully states: 07:21:55 INFO - 41242 INFO TEST-START | Shutdown 07:21:55 INFO - 41243 INFO Passed: 140694 07:21:55 WARNING - 41244 INFO Failed: 1 07:21:55 WARNING - One or more unittests failed. remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/7bba153bad82 remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/3067c3b55a51

(I've filed bug 1043433 for getting more useful log error summaries for this failure mode)

Markus, can you try this patch on Mac to see if it breaks Mac rendering somehow? Mac doesn't care about UpdateOpaqueRegion so it's unclear what effect this patch would have on Mac. Are we altering subpixel AA in Mac chrome perhaps? Thanks!

With the patch applied Mac chrome still has correct subpixel text AA. All layers in the window are completely opaque so we're probably not even hitting the call to IsItemAreaInWindowOpaqueRegion.

Thanks Markus! I have no idea how this patch caused Mac test failures, then.

Oh, I missed the fact that this caused test failures. In the full log at https://tbpl.mozilla.org/php/getParsedLog.php?id=44517570&full=1&branch=mozilla-inbound I see many instances of this assertion: 07:18:48 INFO - 29560 INFO [Parent 1267] ###!!! ASSERTION: Shouldn't return empty rect: '!rect.IsEmpty()', file ../../dist/include/nsRegion.h, line 421 If that's what makes the test run fail, it's probably due to bug 1042327 and not due to this bug.

this looks like same bug, I guess. Nightly 34.0a1 (2014-07-25)

(In reply to Markus Stange [:mstange] from comment #17) > If that's what makes the test run fail, it's probably due to bug 1042327 and > not due to this bug. Duh, you're right of course. Sorry. I'll do a try run.

Is this the same cause of the following bug?: Visit http://www.noip.com/free/ When the page is scrolled up far enough, the tab bar gains a black background. When the page is scrolled down far enough, the black background disappears.

(In reply to IU from comment #22) > Is this the same cause of the following bug?: > > Visit http://www.noip.com/free/ > > When the page is scrolled up far enough, the tab bar gains a black > background. When the page is scrolled down far enough, the black background > disappears. There's a YouTube video embedded on that page, so that would be a "Yes".

Black bar is still.

The status here is that the reftest fails on Android (only), and I think that's because the test just updates a transform on a DIV and takes the nsIFrame::TryUpdateTransformOnly optimization path. But that path does nothing to trigger the invalidation events that reftests rely on. I'm going to try to work around this for this bug by adding extra invalidation. https://tbpl.mozilla.org/?tree=Try&rev=d48beca56d37

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #25) > I'm going to try to work around this for this bug by adding extra > invalidation. I'm sure you know what you're doing, but if the test is bad, isn't it better to fix the test than derive a patch that, to my unskilled mind, might be less efficient and lead to future problems?

(In reply to IU from comment #26) > I'm sure you know what you're doing, but if the test is bad, isn't it better > to fix the test than derive a patch that, to my unskilled mind, might be > less efficient and lead to future problems? No, I was just talking about adding something to the test to trigger extra invalidation. Latest try push here: https://tbpl.mozilla.org/?tree=Try&rev=54cf9049ec39 There's only one issue: a bizarre single black pixel on WinXP. Probably needs investigation.

Roc, can you request the uplift for 33? (aurora). Thanks

This doesn't need Aurora uplift since bug 1022612 was backed out of Aurora.

OK. Thanks

Reproduced with Nightly 2014-07-21 on Windows 7 64-bit with STR from comment 0. Verified as fixed with Firefox 34.0b1 build 2 (Build ID: 20141014134955) on Windows 7 64-bit.