Closed Bug 550716 Opened 10 years ago Closed 10 years ago

There is a black line appears in Google.com fade effect

Categories

(Core :: Layout, defect, P2)

defect

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.
Attached image screenshot
Version: unspecified → Trunk
I'm seeing a black line too with latest Trunk under Linux. Confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Product: Firefox → Core
QA Contact: general → general
Fwiw, I tried the patch in bug 549630 - it did not help.
Hardware: x86 → All
Assignee: nobody → roc
blocking2.0: --- → ?
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.
Attached patch fixSplinter Review
Attachment #431061 - Flags: review?(matspal)
Whiteboard: [needs review]
Comment on attachment 431061 [details] [diff] [review]
fix

r=mats
Attachment #431061 - Flags: review?(matspal) → review+
Assignee: roc → nobody
Component: General → Layout
QA Contact: general → layout
Whiteboard: [needs review]
Assignee: nobody → roc
Whiteboard: [needs landing]
Is this patch waiting on something to be committed?
It's waiting for the tree to be non-broken while I have to time to check stuff in.
http://hg.mozilla.org/mozilla-central/rev/20a2dea77cd3
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [needs landing]
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
blocking2.0: ? → final+
Priority: -- → P2
You need to log in before you can comment on or make changes to this bug.