Closed Bug 433917 Opened 16 years ago Closed 16 years ago

Nested opacity causing painting errors, stuff not showing up

Categories

(Core :: Graphics, defect, P1)

x86
All
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: martijn.martijn, Assigned: vlad)

References

()

Details

(Keywords: regression, testcase, verified1.9.1)

Attachments

(1 file)

Attached file testcase
See testcase, I don't see the first line in current trunk build at all and the second line disappears partly after selecting the text inside it and then collapsing the selection.

Not sure when this regressed (Ria?).
Ok, thanks, so that means this is a cairo issue then.
Component: Layout: View Rendering → GFX: Thebes
Flags: wanted1.9.0.x?
QA Contact: layout.view-rendering → thebes
Flags: blocking1.9?
The testcase shows the bug on Linux (Ubuntu 8.04), as well.  First line is just completely white, unless I highlight it, which then gives me gray text on a white background.
I see the problem on Linux both before and after the given regression date.
Vlad: we need your eyes on this stat to tell us if we need to take a quick ride along for RC2 or if it can wait for 3.0.x
Flags: in-testsuite?
Flags: blocking1.9?
Flags: blocking1.9-
(In reply to comment #4)
> unless I highlight it, which then gives me gray text on a
> white background.

(Actually, it's not gray text, it's more like "brittle"/skinny black text.)
Flags: blocking1.9? → blocking1.9-
I'll take a look here; I'm guessing we should just wait for 3.0.x, though.
Assignee: nobody → vladimir
Looking closer at the site I reported in 435686 this is a standard phpbb forum using a pretty-much off-the-shelf css/style. I'd imagine this would render quick-reply textboxes unusable on quite a number of phpbb-based sites.
This seems to fail if the outermost div (the one with just "opacity: 0.99") has a non-opaque background color, including the default 'transparent'.  Setting background: white or any other solid color results in correct rendering, setting background: rgba(255,0,0,0.5) does not.  Still looking.
I created a cairo testcase for this and sent it off to the cairo list -- Antoine tracked it down to a bug inside the MMX version of a pixman compositing routine (he didn't send his results to the list yet, but he will do so later -- I'll link).  We may be able to fix this for RC2 by disabling that particular MMX routine, but I'd rather just fix this for 3.0.1.
Flags: wanted1.9.0.x? → wanted1.9.0.x+
OS: Windows XP → All
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P1
This is fixed on the trunk.
Fixed by what? Shouldn't this bug be marked fixed then?
Fixed by an updated pixman; I seem to have missed the FIXED button.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Should the testcase work in the latest nightlies, because I'm still having this problem at the moment.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1a2pre) Gecko/20080812020515 Minefield/3.1a2pre ID:20080812020515

Clean profile.
Yes, the testcase should work in the latest nightlies.
I guess you should file a new bug on it, that it's not working for you. I assume that build uses the cairo libraries inside Firefox itself, right?
I suppose it uses the built-in cairo libraries yes. Is there a way to make sure?
Except that the bug is in pixman, and on linux you are likely using the X server's version of pixman, which still has the bug.
Hmm, that's a possibility yes. Any way to force firefox to use the patched libraries on linux?
Flags: wanted1.9.0.x+ → wanted1.9.0.x-
verified FIXED on builds: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090414 Minefield/3.6a1pre ID:20090414030735

and

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090414 Shiretoko/3.5b4pre ID:20090414035212
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: