Closed Bug 201209 Opened 21 years ago Closed 20 years ago
-moz-opacity makes things invisible in GTK2 port
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. :)
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).
Same problem on http://alladyn.art.pl
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
Target Milestone: --- → mozilla1.6beta
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?).
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: 20 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.
You need to log in before you can comment on or make changes to this bug.