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

RESOLVED FIXED

Status

()

Core
Layout
P2
normal
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: Can, Assigned: roc)

Tracking

({regression, testcase, top100})

Trunk
regression, testcase, top100
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(blocking2.0 final+)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

8 years ago
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.
(Reporter)

Comment 1

8 years ago
Created attachment 430875 [details]
screenshot
(Reporter)

Updated

8 years ago
Version: unspecified → Trunk

Comment 2

8 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
Component: General → General
Product: Firefox → Core
QA Contact: general → general
Fwiw, I tried the patch in bug 549630 - it did not help.
Keywords: regression, testcase-wanted, top100
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.
Whiteboard: [needs review]
Comment on attachment 431061 [details] [diff] [review]
fix

r=mats
Attachment #431061 - Flags: review?(matspal) → review+

Updated

8 years ago
Assignee: roc → nobody
Component: General → Layout
Keywords: testcase-wanted → testcase
QA Contact: general → layout
Whiteboard: [needs review]

Updated

8 years ago
Assignee: nobody → roc
Whiteboard: [needs landing]

Comment 8

8 years ago
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
Last Resolved: 8 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [needs landing]

Comment 11

8 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
blocking2.0: ? → final+
Priority: -- → P2
You need to log in before you can comment on or make changes to this bug.