Closed
Bug 550716
Opened 14 years ago
Closed 14 years ago
There is a black line appears in Google.com fade effect
Categories
(Core :: Layout, defect, P2)
Core
Layout
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
blocking2.0 | --- | final+ |
People
(Reporter: vadi.iletisim, Assigned: roc)
References
()
Details
(Keywords: regression, testcase, top100)
Attachments
(3 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; tr; rv:1.9.3a3pre) Gecko/20100305 Minefield/3.7a3pre Firefox/3.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; tr; rv:1.9.3a3pre) Gecko/20100305 Minefield/3.7a3pre Firefox/3.6 Here is the Google's new fade effect at search page. http://mashable.com/2009/12/02/google-fade-in/ http://www.seroundtable.com/archives/020907.html At nightly trunk builds, when google.com fade effect begins, a black line appears under the search buttons. Here is the screenshot: http://i.imgur.com/lozEv.jpg Reproducible: Always Steps to Reproduce: 1.Open www.google.com, dont move the mouse cursor. 2. Move the mouse cursor 3. Black line appears under the search buttons. http://i.imgur.com/lozEv.jpg Actual Results: There shouldn't be a black line.
Comment 2•14 years ago
|
||
I'm seeing a black line too with latest Trunk under Linux. Confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Updated•14 years ago
|
Product: Firefox → Core
QA Contact: general → general
Comment 3•14 years ago
|
||
Fwiw, I tried the patch in bug 549630 - it did not help.
Hardware: x86 → All
Assignee | ||
Updated•14 years ago
|
Assignee: nobody → roc
blocking2.0: --- → ?
Assignee | ||
Comment 4•14 years ago
|
||
Assignee | ||
Comment 5•14 years ago
|
||
The bug here is that we mark the layer for the translucent element as opaque because the associated display item is opaque, but the layer bounds have been set to the bounds of the display item, *rounded out*. We should just snap the layer bounds to nearest pixel boundaries, instead. That's effectively what we used to do in nsDisplayOpacity::Paint.
Assignee | ||
Comment 6•14 years ago
|
||
Attachment #431061 -
Flags: review?(matspal)
Assignee | ||
Updated•14 years ago
|
Whiteboard: [needs review]
Comment 7•14 years ago
|
||
Comment on attachment 431061 [details] [diff] [review] fix r=mats
Attachment #431061 -
Flags: review?(matspal) → review+
Updated•14 years ago
|
Assignee: roc → nobody
Component: General → Layout
Keywords: testcase-wanted → testcase
QA Contact: general → layout
Whiteboard: [needs review]
Updated•14 years ago
|
Assignee: nobody → roc
Assignee | ||
Updated•14 years ago
|
Whiteboard: [needs landing]
Comment 8•14 years ago
|
||
Is this patch waiting on something to be committed?
Assignee | ||
Comment 9•14 years ago
|
||
It's waiting for the tree to be non-broken while I have to time to check stuff in.
Assignee | ||
Comment 10•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/20a2dea77cd3
Status: NEW → RESOLVED
Closed: 14 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [needs landing]
Comment 11•14 years ago
|
||
Verified fixed using nightly build Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a3pre) Gecko/20100315 Minefield/3.7a3pre
Assignee | ||
Updated•14 years ago
|
blocking2.0: ? → final+
Priority: -- → P2
You need to log in
before you can comment on or make changes to this bug.
Description
•