1041530 - black bars on tab bar when youtube.com tab is active

Status: VERIFIED FIXED

(Core :: Layout, defect)

Description

[Patrick]

Attachment: youtube bug A.png

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

Comment 1

[Patrick]

Attachment: youtube bug B.png

Comment 2

[Alice0775 White]

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

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: Be more careful about contributing opaque areas to the window region

Comment 5

[luca892]

[Tracking Requested - why for this release]:

Comment 6

[luca892]

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

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/ed7a32143aeb

Comment 12

[Ed Morley [:emorley]]

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

Comment 13

[Ed Morley [:emorley]]

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

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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!

Comment 15

[Markus Stange [:mstange]]

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.

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Thanks Markus!

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

Comment 17

[Markus Stange [:mstange]]

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.

Comment 18

[Dāvis]

Attachment: youtube_snapshot.png

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

Comment 19

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 20

[Robert O'Callahan (:roc) (email my personal email if necessary)]

https://tbpl.mozilla.org/?tree=Try&rev=9cfbd2ed1ff6

Comment 21

[Robert O'Callahan (:roc) (email my personal email if necessary)]

https://tbpl.mozilla.org/?tree=Try&rev=5c8aadca2c76

Comment 22

[IU]

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.

Comment 23

[Leman Bennett [Omega]]

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

Comment 24

[pawel]

Black bar is still.

Comment 25

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 26

[IU]

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

Comment 27

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 28

[Robert O'Callahan (:roc) (email my personal email if necessary)]

http://hg.mozilla.org/integration/mozilla-inbound/rev/80a866643304

Comment 29

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/80a866643304

Comment 35

[Sylvestre Ledru [:Sylvestre]]

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

Comment 36

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 37

[Sylvestre Ledru [:Sylvestre]]

OK. Thanks

Comment 38

[Ada [:adalucinet]]

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.