Closed
Bug 1041530
Opened 10 years ago
Closed 10 years ago
black bars on tab bar when youtube.com tab is active
Categories
(Core :: Layout, defect)
Tracking
()
VERIFIED
FIXED
mozilla34
Tracking | Status | |
---|---|---|
firefox33 | - | unaffected |
firefox34 | + | verified |
People
(Reporter: patrick.beuks, Assigned: roc)
References
Details
(Keywords: regression)
Attachments
(4 files)
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 2•10 years ago
|
||
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
status-firefox33:
--- → affected
tracking-firefox33:
--- → ?
Component: Untriaged → Layout
Ever confirmed: true
Keywords: regression
Product: Firefox → Core
Assignee | ||
Comment 3•10 years ago
|
||
Attachment #8460150 -
Flags: review?(matt.woodrow)
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → roc
Status: NEW → ASSIGNED
Updated•10 years ago
|
Attachment #8460150 -
Flags: review?(matt.woodrow) → review+
[Tracking Requested - why for this release]:
tracking-firefox34:
--- → ?
status-firefox34:
--- → ?
i was trying to add that firefox 34 has this bug too, but couldnt flag as "affected"
Assignee | ||
Comment 10•10 years ago
|
||
Comment 12•10 years ago
|
||
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•10 years ago
|
||
(I've filed bug 1043433 for getting more useful log error summaries for this failure mode)
Assignee | ||
Comment 14•10 years ago
|
||
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!
Assignee | ||
Updated•10 years ago
|
Flags: needinfo?(mstange)
Comment 15•10 years ago
|
||
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)
Assignee | ||
Comment 16•10 years ago
|
||
Thanks Markus!
I have no idea how this patch caused Mac test failures, then.
Comment 17•10 years ago
|
||
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•10 years ago
|
||
this looks like same bug, I guess. Nightly 34.0a1 (2014-07-25)
Assignee | ||
Comment 19•10 years ago
|
||
(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.
Assignee | ||
Comment 20•10 years ago
|
||
Assignee | ||
Comment 21•10 years ago
|
||
Updated•10 years ago
|
Comment 22•10 years ago
|
||
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•10 years ago
|
||
(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•10 years ago
|
||
Black bar is still.
Assignee | ||
Comment 25•10 years ago
|
||
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•10 years ago
|
||
(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?
Assignee | ||
Comment 27•10 years ago
|
||
(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.
Assignee | ||
Comment 28•10 years ago
|
||
Comment 29•10 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
QA Whiteboard: [qa+]
Comment 35•10 years ago
|
||
Roc, can you request the uplift for 33? (aurora). Thanks
Flags: needinfo?(roc)
Assignee | ||
Comment 36•10 years ago
|
||
This doesn't need Aurora uplift since bug 1022612 was backed out of Aurora.
Flags: needinfo?(roc)
Comment 37•10 years ago
|
||
OK. Thanks
Comment 38•10 years ago
|
||
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.
Description
•