Closed Bug 201209 Opened 20 years ago Closed 19 years ago

-moz-opacity makes things invisible in GTK2 port

Categories

(Core Graveyard :: GFX: Gtk, defect, P1)

x86
Linux

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.6beta

People

(Reporter: elanthis, Assigned: dbaron)

References

()

Details

(Whiteboard: [patch])

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

When I apply opacity in Mozilla 1.3 or 1.4a using CSS (using -moz-opacity),
objects only appear at all if opacity is set to 1.  Any value less than 1
results in the object being completely invisible.  It works as expected in 1.2.

Also, only decimal values have an effect... 0.7 will trigger the above bug, but
70% results in no change - it appears at full 100% opacity given any percentage
value.

Reproducible: Always

Steps to Reproduce:
1. Set an item to less than .9 opacity w/ CSS.
2. See the item be invisible.


Actual Results:  
Didn't see what I thought I would - a partially visible item.

Expected Results:  
Shown a partially visible item.

This happens with the GTK2/Xft binaries available on ftp.mozilla.org.  Guess it
might be a GTK2-renderer bug?  Haven't tried with any non-GTK2 version of
Mozilla 1.3+.  This is all on RedHat8 and 9.  (I can check more indepth with
more browser versions and OS's at home.)
Two notes:

1)  Percentage opacity has been removed.  So no, it won't work.  ;)
2)  This works fine for me with gtk1 builds...
Nice.  Doesn't work here on my gtk2 build, that's for damn sure.  Something is
screwed up. :)
Blocks: gtk2
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: opacity odd behaviour → -moz-opacity makes things invisible in GTK2 port
Does this depend on your screen depth? There is a known bug with GTK rendering
onto 24-bit offscreen surfaces which might be triggered more often with GTK2.
Confirmed: -moz-opacity is broken in the Debian Mozilla 1.3.1 package and the
Firebird GTK2 builds. Let's vote for this bug...
*** Bug 214072 has been marked as a duplicate of this bug. ***
Here's a nice testcase:
http://www.w3.org/Talks/2003/0521-CSS-WWW2003/opacity1.html

Firebird 0.7-gtk1 renders this perfectly.
Firebird 0.7-gtk2 displays just a black screen. (24-bit on XFree 4.3 with NVidia
drivers).

I hit the same problem with the official Linux mozilla1.5 build. And this makes
it a serious problemas we want 1.5 to be a end-user release.

Should't the bug be at least major? 
Changing the severity.
Severity: normal → major
If the build you're using doesn't have --enable-default-toolkit=gtk2 in
about:buildconfig, then it's not this bug.

(There is another bug somewhere about problems on GTK1 with certain color
depths, I think.)

It's probably best to wait until roc lands bug 212366 before looking at this too
closely.
Yes, I used the builds from
http://ftp.mozilla.org/pub/mozilla.org/mozilla/yum/SeaMonkey/releases/1.5/redhat/9/
described on the Realeases page (http://www.mozilla.org/releases/#1.5) as "RPMS
for Red Hat Linux 9 with Xft and Gtk2".
I think I've figured this out.  The bpp member of GdkImage is document as bytes
per pixel.  GDK1 (based on Red Hat 9's gtk+-1.2.10/gdk/gdkimage.c) sometimes set
it as bytes per pixel and sometimes set is a bits per pixel (and for the case
that mattered to us, it was presumably using bits per pixel).  GDK2 is correct
and always sets is at bytes per pixel.

Patch coming shortly, once I test it.  I've already tested that the removal of
the ">> 3" in nsDrawingSurfaceGTK::Lock fixes this for GTK2, but it presumably
breaks GTK1.  I'm planning to use (GDK_IMAGE_XIMAGE(mImage)->bits_per_pixel + 7)
/ 8, which is the same math that GDK uses internally to set bpp.  (I'm probably
going to be lazy and test it only in my GTK2 build, though, and hope someone
else can test on GTK1.)
Assignee: blizzard → dbaron
Priority: -- → P1
Whiteboard: [patch]
Target Milestone: --- → mozilla1.6beta
Attached patch patchSplinter Review
Comment on attachment 134628 [details] [diff] [review]
patch

I also remember roc mentioning problems with GTK1 at certain color depths. 
Perhaps this will fix that as well (might bits_per_pixel have been 15 in some
cases?).
Attachment #134628 - Flags: superreview?(roc)
Attachment #134628 - Flags: review?(bryner)
Comment on attachment 134628 [details] [diff] [review]
patch

Looks good to me.
Attachment #134628 - Flags: review?(bryner) → review+
Comment on attachment 134628 [details] [diff] [review]
patch

Looks good. I tried it on GTK1 and it seems to work OK.
Attachment #134628 - Flags: superreview?(roc) → superreview+
Fix checked in to trunk, 2003-11-01 19:14 -0800.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
> Here's a nice testcase:
> http://www.w3.org/Talks/2003/0521-CSS-WWW2003/opacity1.html

What _should_ this page be rendered as? On OS X firefox 0.8 this shows a black page.
Re comment 17: that's bug 228441
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.