Closed Bug 1041530 Opened 7 years ago Closed 7 years ago

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

Categories

(Core :: Layout, defect)

33 Branch
x86_64
Windows 7
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla34
Tracking Status
firefox33 - unaffected
firefox34 + verified

People

(Reporter: patrick.beuks, Assigned: roc)

References

Details

(Keywords: regression)

Attachments

(4 files)

Attached image 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
Attached image youtube bug B.png
Hardware: x86 → x86_64
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
Blocks: 1022612
Status: UNCONFIRMED → NEW
Component: Untriaged → Layout
Ever confirmed: true
Keywords: regression
Product: Firefox → Core
Assignee: nobody → roc
Status: NEW → ASSIGNED
Duplicate of this bug: 1042118
Attachment #8460150 - Flags: review?(matt.woodrow) → review+
[Tracking Requested - why for this release]:
i was trying to add that firefox 34 has this bug too, but couldnt flag as "affected"
Duplicate of this bug: 1042875
Duplicate of this bug: 1042985
Duplicate of this bug: 1043142
Duplicate of this bug: 1043359
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!
Flags: needinfo?(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.
Flags: needinfo?(mstange)
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.
Attached image youtube_snapshot.png
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.
https://hg.mozilla.org/mozilla-central/rev/80a866643304
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
Duplicate of this bug: 1046754
Duplicate of this bug: 1046774
No longer blocks: 1043498
Duplicate of this bug: 1043498
Duplicate of this bug: 1045986
Duplicate of this bug: 1054212
Roc, can you request the uplift for 33? (aurora). Thanks
Flags: needinfo?(roc)
This doesn't need Aurora uplift since bug 1022612 was backed out of Aurora.
Flags: needinfo?(roc)
Depends on: 1077846
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.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.