Last Comment Bug 70798 - Ability to have transparent background on popups
: Ability to have transparent background on popups
Status: VERIFIED FIXED
: verified1.8.1.1
Product: Core
Classification: Components
Component: XUL (show other bugs)
: Trunk
: All All
: -- enhancement with 2 votes (vote)
: mozilla1.9alpha1
Assigned To: neil@parkwaycc.co.uk
:
Mentors:
: 92748 308818 (view as bug list)
Depends on: 71112 364424 40795 351716
Blocks: 92748 242621 307204 325407
  Show dependency treegraph
 
Reported: 2001-03-03 11:11 PST by Brian 'netdragon' Bober
Modified: 2008-08-02 21:14 PDT (History)
22 users (show)
mtschrep: blocking1.8.1.1-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Example (83.57 KB, image/jpeg)
2001-03-03 11:20 PST, Brian 'netdragon' Bober
no flags Details
With the new view manager (2.68 KB, image/gif)
2001-03-06 19:13 PST, Brian 'netdragon' Bober
no flags Details
Transparent Window (144.69 KB, image/jpeg)
2001-12-09 05:07 PST, Brian 'netdragon' Bober
no flags Details
transparent poup menu testcase (909 bytes, application/vnd.mozilla.xul+xml)
2005-06-14 09:19 PDT, Martijn Wargers [:mwargers] (not working for Mozilla)
no flags Details
branch layout change (1.80 KB, patch)
2006-09-02 16:28 PDT, neil@parkwaycc.co.uk
roc: review+
roc: superreview+
mtschrep: approval1.8.1-
Details | Diff | Splinter Review
Example theme changes (1.38 KB, patch)
2006-09-02 16:31 PDT, neil@parkwaycc.co.uk
no flags Details | Diff | Splinter Review
Round icons to demonstrate transparency (2.31 KB, application/zip)
2006-09-02 16:34 PDT, neil@parkwaycc.co.uk
no flags Details
trunk layout changes (5.99 KB, patch)
2006-09-03 16:06 PDT, neil@parkwaycc.co.uk
roc: review+
roc: superreview+
Details | Diff | Splinter Review
Permit chrome documents only (856 bytes, patch)
2006-09-13 01:51 PDT, neil@parkwaycc.co.uk
roc: review+
roc: superreview+
Details | Diff | Splinter Review
Like this? (2.06 KB, patch)
2006-09-13 02:32 PDT, neil@parkwaycc.co.uk
no flags Details | Diff | Splinter Review
Use the docshell type (1.01 KB, patch)
2006-09-13 16:09 PDT, neil@parkwaycc.co.uk
bzbarsky: review+
bzbarsky: superreview+
Details | Diff | Splinter Review
Final complete version (2.20 KB, patch)
2006-09-14 16:29 PDT, neil@parkwaycc.co.uk
roc: review+
roc: superreview+
mtschrep: approval1.8.1-
dveditz: approval1.8.1.1+
Details | Diff | Splinter Review
Screenshot of problem with Walnut popup (27.70 KB, image/jpeg)
2006-09-22 05:09 PDT, Alfred Kayser
no flags Details

Description Brian 'netdragon' Bober 2001-03-03 11:11:37 PST
If you try to set background-color: transparent; on XUL <popup>s, the 
background doesn't change to transparent. It would be nice to be able to make a 
transparent background for if you wanted to have a transparent gif appear.

An example of this would be the NSEW artifact for panning.
Comment 1 Brian 'netdragon' Bober 2001-03-03 11:20:13 PST
Created attachment 26707 [details]
Example
Comment 2 Brian 'netdragon' Bober 2001-03-03 11:22:07 PST
That was what the popup looked like with this css.

popup.panning-class
{
    	border-style: none;
    	background-color: transparent;
}
Comment 3 Boris Zbarsky [:bz] (TPAC) 2001-03-03 13:45:15 PST
Brian, is this with the old viewmanager or with the new one?
Comment 4 Brian 'netdragon' Bober 2001-03-03 18:07:37 PST
What is a viewmanager?
Comment 5 Brian 'netdragon' Bober 2001-03-03 18:10:13 PST
I have the build from 2/22
Comment 6 Boris Zbarsky [:bz] (TPAC) 2001-03-03 23:30:17 PST
The viewmanager is what handles compositing of various widgets.  In particular,
the old viewmanager does not properly support transparent backgrounds on many
windows.

Try: 

user_pref("nglayout.debug.enable_scary_view_manager", true);

to enable the new viewmanager and try this with it.
Comment 7 Peter Trudelle 2001-03-06 17:10:27 PST
->pink
Comment 8 Mike Pinkerton (not reading bugmail) 2001-03-06 17:20:15 PST
since OS windows are used for xul popups, don't we have to have translucent OS 
windows to get this w/out a rewrite of XUL popups to use something more 
lightweight?
Comment 9 Brian 'netdragon' Bober 2001-03-06 18:50:04 PST
I know that Windows can do transparent windows background. What you can do is 
not paint the background and set it to transparent.
Comment 10 Brian 'netdragon' Bober 2001-03-06 19:13:04 PST
Created attachment 26975 [details]
With the new view manager
Comment 11 Skewer 2001-08-29 23:16:43 PDT
The transparent backgrounds you see on desktop windows are set transparent using
a complex polygon-region API. This would be very difficult (if not completely
impossible) to coordinate with things like transparent images and scrolling.
However, if the XUL popups are rendered in the same window, Mozilla can handle
transparency effects internally (and probably even support alpha transparency
effects).
Comment 12 Brian 'netdragon' Bober 2001-09-23 13:17:25 PDT
It is not necessary to do all that polygon region nonsense imho. All you have to
do is make a rectangular window with a transparent background. If you did that,
I would be perfectly happy. Perhaps, you could even make it so that if you click
on the transparent part of the window, it activates the window under it as if
they clicked on that window. That way we wouldn't have to fool around with
polygons (which probably aren't supported on every OS).
Comment 13 Skewer 2001-09-23 14:51:03 PDT
netdemon: That is not true. It is only possible to make desktop windows
transparent through the polygonal region API in Windows. There is *no other way*
to do it. If it's a desktop window in Windows, it's either a rectangle or it has
polygonal regions.
Comment 14 R.K.Aa. 2001-12-09 02:06:05 PST
dup of bug 40795?
Comment 15 Brian 'netdragon' Bober 2001-12-09 05:04:09 PST
You can make a transparent background by not painting the background. I've done
it.  The thing is that if you click on this "seemingly nonexistant" part of the
window, the messages will be sent to the window anyway. Therefore, it is there,
just not painted.

What you do is set the window to transparent by using NULL brush for the
background for WNDCLASSEX's hbrBackground.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winclass_450y.asp

Comment 16 Brian 'netdragon' Bober 2001-12-09 05:07:00 PST
Created attachment 60997 [details]
Transparent Window

I left the border on so you can see where the window is. Notice the hello world
that was drawn in the window. If the window moves, the background stays the
same, so you would have to hide and reshow to move it.
Comment 17 Brian 'netdragon' Bober 2001-12-09 05:10:33 PST
But all I need to do is have the window shown, drawn transparently and taken
away. If this can be done on all oses, then there is no problem. You can even
move it by hiding it and showing it on windows. Of course, if you click on it
where it is trasnsparent, it won't click what's behind it. That doesn't matter
in my case though because I just want it to appear transparent. 

Comment 18 Brian 'netdragon' Bober 2001-12-09 05:13:49 PST
I actually would be perfectly happy for now if it was handled internally. That
way, I could just place the NSEW artifact inside the window. For instance: if
they clicked on the edge and it would extend out the window, I would just move
it over a little.
Comment 19 Brian 'netdragon' Bober 2001-12-09 05:17:26 PST
I just realized that I don't think it could be handled internally any
differently than I mentioned, since the sidebar, and navigation buttons, menu,
etc are all in separate windows. Autoscroll/panning is not going to be just for
web pages. 

For now, I am going to have to just have it be a regular window, which is
unattractive imho.
Comment 20 Boris Zbarsky [:bz] (TPAC) 2001-12-09 08:06:26 PST
Brian, not painting the background on Linux will show complete and utter garbage
in that part of the window, not whatever is below it.  So this is not an
acceptable XP solution.
Comment 21 Robert O'Callahan (:roc) (email my personal email if necessary) 2004-02-26 00:19:14 PST
*** Bug 92748 has been marked as a duplicate of this bug. ***
Comment 22 Robert O'Callahan (:roc) (email my personal email if necessary) 2004-02-26 00:23:07 PST
This can be implemented via the transparent chrome support.
Comment 23 Martijn Wargers [:mwargers] (not working for Mozilla) 2005-06-14 09:19:02 PDT
Created attachment 186214 [details]
transparent poup menu testcase

So can/should this work now since bug 113232 et all got fixed?
Removing this line:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/xul/base/src/nsMenuPopupFrame.cpp&rev=1.256&root=/cvsroot#207

doesn't work for me.
The popup menu gets a grayish background color, but doesn't become transparent.
Comment 24 Robert O'Callahan (:roc) (email my personal email if necessary) 2005-06-14 15:09:10 PDT
This is not supposed to work. Additional work needs to be done. It's probably
not hard...
Comment 25 Martijn Wargers [:mwargers] (not working for Mozilla) 2005-08-09 02:01:03 PDT
I think it would be the solution for bug 242621.
Comment 26 Robert O'Callahan (:roc) (email my personal email if necessary) 2005-08-09 13:05:14 PDT
Yeah. Something to work on for 1.9. Have a go, Martijn :-).
Comment 27 Christian :Biesinger (don't email me, ping me on IRC) 2005-09-01 07:56:24 PDT
http://lxr.mozilla.org/seamonkey/source/layout/generic/nsContainerFrame.cpp#543
Comment 28 Christian :Biesinger (don't email me, ping me on IRC) 2005-09-16 06:58:05 PDT
*** Bug 308818 has been marked as a duplicate of this bug. ***
Comment 29 Christian :Biesinger (don't email me, ping me on IRC) 2006-02-04 05:54:16 PST
-> default owner, I'm clearly not working on this
Comment 30 Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com] 2006-08-26 09:29:10 PDT
Is there someone who could help me write this if nobody else will do it?
Comment 31 Robert O'Callahan (:roc) (email my personal email if necessary) 2006-08-26 13:07:50 PDT
Sure
Comment 32 Robert O'Callahan (:roc) (email my personal email if necessary) 2006-08-26 18:40:19 PDT
The main thing you need to do, maybe the only thing, is to call SetWindowTranslucency on the right widget when the popup is transparent. The code that does this for toplevel windows is here:
http://lxr.mozilla.org/seamonkey/source/layout/generic/nsContainerFrame.cpp#385
Comment 33 Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com] 2006-08-26 19:09:40 PDT
(In reply to comment #32)
> The main thing you need to do, maybe the only thing, is to call
> SetWindowTranslucency on the right widget when the popup is transparent. The
> code that does this for toplevel windows is here:
> http://lxr.mozilla.org/seamonkey/source/layout/generic/nsContainerFrame.cpp#385
> 

I attempted to do something like that at http://lxr.mozilla.org/seamonkey/source/layout/xul/base/src/nsMenuPopupFrame.cpp#194
by changing line 197 to use PR_TRUE (tried both ways), and on line 204 writing
ourView->GetWidget()->SetWindowTranslucency(PR_TRUE); but the only effect was slower menus and popups (I gave my popup background: transparent; for testing)
Comment 34 Robert O'Callahan (:roc) (email my personal email if necessary) 2006-08-26 23:01:12 PDT
You may also need to set -moz-appearance:none on the popup to disable any native theme background painting.
Comment 35 Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com] 2006-08-27 10:15:54 PDT
(In reply to comment #34)
> You may also need to set -moz-appearance:none on the popup to disable any
> native theme background painting.

Ok, that does give me a transparent popup, but I expected my popup to be totally invisible.  Instead, it looks more like it has low opacity, and it has a drop shadow like context menus and tooltips normally do on XP.
Comment 36 Boris Zbarsky [:bz] (TPAC) 2006-08-27 10:27:03 PDT
The drop shadow is drawn by the OS itself; it's a separate window the OS synthesizes.  You'd have to change the window class of the popup to get rid of it.
Comment 37 Martijn Wargers [:mwargers] (not working for Mozilla) 2006-08-28 06:12:16 PDT
Btw, there is bug 118379 that talks about a css way of controlling the drop shadow of the popup.
Comment 38 neil@parkwaycc.co.uk 2006-09-02 16:04:05 PDT
Popup transparency is majorly broken on trunk either cairo or non-cairo,
but I have a working branch patch that I've tested on GTK and Windows.
Comment 39 neil@parkwaycc.co.uk 2006-09-02 16:28:22 PDT
Created attachment 236567 [details] [diff] [review]
branch layout change

This actually enables support for transparency, but for best effect should be combined with the following theme changes for SeaMonkey ;-)
Comment 40 neil@parkwaycc.co.uk 2006-09-02 16:31:32 PDT
Created attachment 236568 [details] [diff] [review]
Example theme changes

These changes are not final because this only works on Windows and Linux.
Comment 41 neil@parkwaycc.co.uk 2006-09-02 16:34:21 PDT
Created attachment 236569 [details]
Round icons to demonstrate transparency
Comment 42 neil@parkwaycc.co.uk 2006-09-02 16:38:07 PDT
>These changes are not final because this only works on Windows and Linux.
On Windows XP/2003 you'll also want the fix for bug 313927.
Comment 43 neil@parkwaycc.co.uk 2006-09-03 16:06:14 PDT
Created attachment 236661 [details] [diff] [review]
trunk layout changes

Note: only tested on a non-cairo build so far.
Comment 44 neil@parkwaycc.co.uk 2006-09-07 01:52:01 PDT
Comment on attachment 236661 [details] [diff] [review]
trunk layout changes

Checked in but not sure whether to resolve as fixed as it's not even been tested on cairo.
Comment 45 Olli Pettay [:smaug] (TPAC) 2006-09-07 04:08:26 PDT
This broke menus on linux-cairo.
When moving mouse fast over separator-menuitems, they don't get repainted (or 
something like that) after mouseout/hover.
Comment 46 Robert O'Callahan (:roc) (email my personal email if necessary) 2006-09-07 08:27:49 PDT
Hey Neil, I just realized that we need to make sure untrusted code can't do this. I think we should restrict it to chrome shells for now.
Comment 47 neil@parkwaycc.co.uk 2006-09-10 16:20:12 PDT
Comment on attachment 236567 [details] [diff] [review]
branch layout change

Has been on trunk for a few days and the only (since fixed) regression has been with gtk2-cairo builds which doesn't apply on branch anyway.
Comment 48 Mike Schroepfer 2006-09-11 18:25:49 PDT
Do we need to address anything in comment 46?

(In reply to comment #47)
> (From update of attachment 236567 [details] [diff] [review] [edit])
> Has been on trunk for a few days and the only (since fixed) regression has been
> with gtk2-cairo builds which doesn't apply on branch anyway.
> 

Comment 49 neil@parkwaycc.co.uk 2006-09-12 02:04:50 PDT
(In reply to comment #48)
>Do we need to address anything in comment 46?
bz's opinion was that you can already confuse the user with opaque popups.
Comment 50 Boris Zbarsky [:bz] (TPAC) 2006-09-12 10:05:17 PDT
Er.. no.  My opinion was that you can confuse the user a heck of a lot more with transparent popups than with opaque ones.  I agree with roc -- non-chrome should not be able to do this.
Comment 51 Mike Schroepfer 2006-09-12 10:29:20 PDT
Comment on attachment 236567 [details] [diff] [review]
branch layout change

Given the continued discussion on implementation, lack of compelling need for this immediately, and fact that this is not zero-risk branch drivers are minusing this bug.
Comment 52 David Baron :dbaron: ⌚️UTC+1 (busy September 14-25) 2006-09-12 11:04:48 PDT
Do we need a blocking1.9? bug filed on making this chrome-only?
Comment 53 Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com] 2006-09-12 15:32:04 PDT
(In reply to comment #50)
> Er.. no.  My opinion was that you can confuse the user a heck of a lot more
> with transparent popups than with opaque ones.  I agree with roc -- non-chrome
> should not be able to do this.
> 

How, exactly?
Comment 54 Boris Zbarsky [:bz] (TPAC) 2006-09-12 15:37:21 PDT
Transparent popups could capture click events, for example.  Including ones outside the browser window, if desired.
Comment 55 neil@parkwaycc.co.uk 2006-09-12 17:12:34 PDT
(In reply to comment #54)
>Transparent popups could capture click events, for example.  Including ones
>outside the browser window, if desired.
Not quite sure what you mean here, but if you click on a hole in a transparent popup it will hit the window underneath...
Comment 56 neil@parkwaycc.co.uk 2006-09-12 17:14:18 PDT
(In reply to comment #50)
>Er.. no.  My opinion was that you can confuse the user a heck of a lot more
>with transparent popups than with opaque ones.
I'm sorry, that's not how I understood your reply when I asked you on IRC.
Comment 57 neil@parkwaycc.co.uk 2006-09-12 17:16:56 PDT
(In reply to comment #51)
>lack of compelling need for this
Bug 242621
Comment 58 Robert O'Callahan (:roc) (email my personal email if necessary) 2006-09-12 18:41:32 PDT
You could create a window with alpha values 1/255, no-one would notice.

It should be very easy to just restrict popup translucency to chrome docshells.
Comment 59 neil@parkwaycc.co.uk 2006-09-13 01:51:03 PDT
Created attachment 238174 [details] [diff] [review]
Permit chrome documents only

Chrome documents are a lot easier to detect, if that's OK with you...
Comment 60 Robert O'Callahan (:roc) (email my personal email if necessary) 2006-09-13 02:10:56 PDT
Comment on attachment 238174 [details] [diff] [review]
Permit chrome documents only

+  if (viewHasTransparentContent &&
+    NS_FAILED(GetContent()->GetOwnerDoc()->GetDocumentURI()->SchemeIs("chrome",
+      &viewHasTransparentContent)))
+    viewHasTransparentContent = PR_FALSE;

This is a bit hard to follow. Can you rewrite it as the equivalent "if (viewHasTransparentContent) { rv = ...; if (NS_FAILED(rv)) { viewHasTransparentContent = PR_FALSE; } }"
Comment 61 neil@parkwaycc.co.uk 2006-09-13 02:32:03 PDT
Created attachment 238180 [details] [diff] [review]
Like this?

I actually added two locals to avoid wrapping any lines at all.
Comment 62 Boris Zbarsky [:bz] (TPAC) 2006-09-13 09:45:41 PDT
Having a chrome:// URI in some way doesn't make a document "chrome", imo.  See the various about: documents, for example.

If you want to test the document, imo you should be checking that the NodePrincipal() of the document is the system principal.
Comment 63 Boris Zbarsky [:bz] (TPAC) 2006-09-13 09:46:40 PDT
The point being that simply having a chrome:// URI doesn't mean untrusted content can't touch you.  The principal is what matters.
Comment 64 neil@parkwaycc.co.uk 2006-09-13 12:05:41 PDT
(In reply to comment #58)
>It should be very easy to just restrict popup translucency to chrome docshells.
It was easier than I thought, but I wouldn't say very easy... patch coming up.
Comment 65 neil@parkwaycc.co.uk 2006-09-13 16:09:50 PDT
Created attachment 238315 [details] [diff] [review]
Use the docshell type
Comment 66 Boris Zbarsky [:bz] (TPAC) 2006-09-13 20:17:21 PDT
Comment on attachment 238315 [details] [diff] [review]
Use the docshell type

>Index: nsMenuPopupFrame.cpp
>+    nsCOMPtr<nsISupports> cont = GetContent()->GetOwnerDoc()->GetContainer();

How about GetPresContext()->GetContainer()?

>+    nsCOMPtr<nsIDocShellTreeItem> dsti = do_QueryInterface(cont);

With bfcache, this could be null, in general.  If it is, don't allow transparency?

Rest looks good.  r+sr=bzbarsky with those nits.
Comment 67 neil@parkwaycc.co.uk 2006-09-14 16:29:56 PDT
Created attachment 238544 [details] [diff] [review]
Final complete version
Comment 68 neil@parkwaycc.co.uk 2006-09-18 02:13:02 PDT
Comment on attachment 238544 [details] [diff] [review]
Final complete version

Note: not targeting for Fx2 itself, unless someone really wants bug 242621 fixed.
Comment 69 Mike Schroepfer 2006-09-18 14:04:32 PDT
Comment on attachment 238544 [details] [diff] [review]
Final complete version

RC1 is closed.
Comment 70 Alfred Kayser 2006-09-22 05:09:57 PDT
Created attachment 239644 [details]
Screenshot of problem with Walnut popup

With my theme this causes some issues (or I am getting this transparancy feature wrong). 
Build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060921 Minefield/3.0a1

This is the code I use for the (menu)popups:
popup, menupopup {
  border: 2px solid;
  -moz-border-radius: 6px;
  -moz-border-top-colors: #B26F00 #EED4A2;
  -moz-border-left-colors: #B26F00 #EED4A2;
  -moz-border-right-colors: #893B00 #B26F00;
  -moz-border-bottom-colors: #893B00 #B26F00;
  background: transparent;
  color: black !important;
}
.popup-internal-box {
  background-image: url("chrome://global/skin/hout.png");
}

What I want to achieve is actually simple: rounded corners for my popups, and the background of the popup with this 'hout.png' (wood image).

Am I doing some wrong or is gecko/cairo doing something wrong?
Comment 71 Robert Kaiser 2006-09-22 08:03:27 PDT
Alfred, as I understand it, there is a general bug that a border radius does not actually cut the (rounded) corners of the box off of the box and the background still fills a rectangular shape, not a rounded one. It's only the borser that gets rounded, not the box itself.
This is a different problem though than the transparency of the popup itself.
Comment 72 Alfred Kayser 2006-09-22 09:03:24 PDT
Indeed the 'background painting not following the rounded border' is indeed a longer wellknown problem. The point I am referring is the effect of the letters (the font) and the border lines themselves are sort of transparent.
Comment 73 Boris Zbarsky [:bz] (TPAC) 2006-09-22 09:50:14 PDT
> and the background still fills a rectangular shape

Only for background-image.  background-color works correctly.
Comment 74 Robert Kaiser 2006-09-22 15:28:48 PDT
(In reply to comment #73)
> > and the background still fills a rectangular shape
> 
> Only for background-image.  background-color works correctly.

Ah, right.

Alfred:
Ah, yes, true, the border and fonts don't look completely opaque in you screen shot (the shot is somehow a bit hard to look at though, may be the JPEG compression) 
Comment 75 neil@parkwaycc.co.uk 2006-09-22 15:58:07 PDT
(In reply to comment #70)
>What I want to achieve is actually simple: rounded corners for my popups
Please remember that this feature is a) disabled in content docshells including the about:config context menu and b) only available on Windows and GTK toolkits
Comment 76 Kathleen Brade 2006-10-17 07:03:40 PDT
Thanks Neil for sharing this on irc:
  Mac work (currently not implemented) is covered in bug 307204
  GTK1 was fixed in bug 113232
  GTK2 was fixed in bug 252525
  Win2K+ was fixed in bug 252067
  Win9x was fixed in bug 264708
Comment 77 Mike Schroepfer 2006-11-01 10:19:46 PST
General criteria for dot releases is security, top crash, and major regressions.     
Comment 78 Daniel Veditz [:dveditz] 2006-11-27 17:25:19 PST
This was fixed on trunk Sept 14
Comment 79 Daniel Veditz [:dveditz] 2006-11-27 17:26:30 PST
Comment on attachment 238544 [details] [diff] [review]
Final complete version

apparently caused regression bug 351716 which has not been nominated for the branch, and if that was overlooked have there been others? Not worth the risk in a security release for a "new feature" behavior
Comment 80 neil@parkwaycc.co.uk 2006-11-28 17:01:04 PST
Comment on attachment 238544 [details] [diff] [review]
Final complete version

a) this patch includes the fix for the aforementioned regression b) translucent widgets have been around for two and a half years.
Comment 81 Daniel Veditz [:dveditz] 2006-11-29 12:18:13 PST
Comment on attachment 238544 [details] [diff] [review]
Final complete version

approved for 1.8 branch, a=dveditz for drivers
Comment 82 neil@parkwaycc.co.uk 2006-11-29 16:19:57 PST
Fix checked in to MOZILLA_1_8_BRANCH
Comment 83 Rob Campbell [:rc] (:robcee) 2006-11-30 12:51:59 PST
verified transparent panning icon in OS X using 2006112906.
Comment 84 Olli Pettay [:smaug] (TPAC) 2006-12-21 09:29:53 PST
Is it possible that this caused bug 364424?
On branch that regressed between 20061128 - 20061130
Comment 85 Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com] 2007-03-04 15:17:14 PST
Do transparent popups work on mac?
Comment 86 Robert O'Callahan (:roc) (email my personal email if necessary) 2007-03-04 15:30:11 PST
No, we don't have transparent window code for Mac.

Note You need to log in before you can comment on or make changes to this bug.