Closed
Bug 201209
Opened 21 years ago
Closed 20 years ago
-moz-opacity makes things invisible in GTK2 port
Categories
(Core Graveyard :: GFX: Gtk, defect, P1)
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla1.6beta
People
(Reporter: elanthis, Assigned: dbaron)
References
()
Details
(Whiteboard: [patch])
Attachments
(1 file)
1.28 KB,
patch
|
bryner
:
review+
roc
:
superreview+
|
Details | Diff | Splinter Review |
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.)
![]() |
||
Comment 1•21 years ago
|
||
Two notes: 1) Percentage opacity has been removed. So no, it won't work. ;) 2) This works fine for me with gtk1 builds...
Comment 2•21 years ago
|
||
Nice. Doesn't work here on my gtk2 build, that's for damn sure. Something is screwed up. :)
Blocks: gtk2
![]() |
||
Updated•21 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Updated•21 years ago
|
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...
Assignee | ||
Comment 5•21 years ago
|
||
*** Bug 214072 has been marked as a duplicate of this bug. ***
Comment 6•20 years ago
|
||
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).
Comment 7•20 years ago
|
||
Same problem on http://alladyn.art.pl
Comment 8•20 years ago
|
||
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
Assignee | ||
Comment 9•20 years ago
|
||
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.
Comment 10•20 years ago
|
||
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".
Assignee | ||
Comment 11•20 years ago
|
||
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
Assignee | ||
Comment 12•20 years ago
|
||
Assignee | ||
Comment 13•20 years ago
|
||
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 14•20 years ago
|
||
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+
Assignee | ||
Comment 16•20 years ago
|
||
Fix checked in to trunk, 2003-11-01 19:14 -0800.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment 17•20 years ago
|
||
> 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.
Assignee | ||
Comment 18•20 years ago
|
||
Re comment 17: that's bug 228441
Updated•15 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•