Brian 'netdragon' Bober Reporter
	Description • 24 years ago

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.

	Brian 'netdragon' Bober Reporter
	Comment 2 • 24 years ago

That was what the popup looked like with this css.

popup.panning-class
{
    	border-style: none;
    	background-color: transparent;
}

	Boris Zbarsky [:bzbarsky]
	Comment 3 • 24 years ago

Brian, is this with the old viewmanager or with the new one?

	Brian 'netdragon' Bober Reporter
	Comment 4 • 24 years ago

What is a viewmanager?

	Brian 'netdragon' Bober Reporter
	Comment 5 • 24 years ago

I have the build from 2/22

	Boris Zbarsky [:bzbarsky]
	Comment 6 • 24 years ago

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.

	Peter Trudelle
	Comment 7 • 23 years ago

->pink

	Mike Pinkerton (not reading bugmail)
	Comment 8 • 23 years ago

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?

	Brian 'netdragon' Bober Reporter
	Comment 9 • 23 years ago

I know that Windows can do transparent windows background. What you can do is 
not paint the background and set it to transparent.

	Skewer
	Comment 11 • 23 years ago

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).

	Brian 'netdragon' Bober Reporter
	Comment 12 • 23 years ago

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).

	Skewer
	Comment 13 • 23 years ago

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.

	R.K.Aa.
	Comment 14 • 23 years ago

dup of bug 40795?

	Brian 'netdragon' Bober Reporter
	Comment 15 • 23 years ago

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

	Brian 'netdragon' Bober Reporter
	Comment 16 • 23 years ago

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.

	Brian 'netdragon' Bober Reporter
	Comment 17 • 23 years ago

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. 

	Brian 'netdragon' Bober Reporter
	Comment 18 • 23 years ago

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.

	Brian 'netdragon' Bober Reporter
	Comment 19 • 23 years ago

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.

	Boris Zbarsky [:bzbarsky]
	Comment 20 • 23 years ago

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.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 21 • 20 years ago

*** Bug 92748 has been marked as a duplicate of this bug. ***

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 22 • 20 years ago

This can be implemented via the transparent chrome support.

	Martijn Wargers (dead)
	Comment 23 • 19 years ago

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.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 24 • 19 years ago

This is not supposed to work. Additional work needs to be done. It's probably
not hard...

	Martijn Wargers (dead)
	Comment 25 • 19 years ago

I think it would be the solution for bug 242621.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 26 • 19 years ago

Yeah. Something to work on for 1.9. Have a go, Martijn :-).

	Christian :Biesinger (don't email me, ping me on IRC)
	Comment 27 • 19 years ago

http://lxr.mozilla.org/seamonkey/source/layout/generic/nsContainerFrame.cpp#543

	Christian :Biesinger (don't email me, ping me on IRC)
	Comment 28 • 19 years ago

*** Bug 308818 has been marked as a duplicate of this bug. ***

	Christian :Biesinger (don't email me, ping me on IRC)
	Comment 29 • 19 years ago

-> default owner, I'm clearly not working on this

	Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com]
	Comment 30 • 18 years ago

Is there someone who could help me write this if nobody else will do it?

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 31 • 18 years ago

Sure

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 32 • 18 years ago

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

	Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com]
	Comment 33 • 18 years ago

(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)

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 34 • 18 years ago

You may also need to set -moz-appearance:none on the popup to disable any native theme background painting.

	Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com]
	Comment 35 • 18 years ago

(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.

	Boris Zbarsky [:bzbarsky]
	Comment 36 • 18 years ago

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.

	Martijn Wargers (dead)
	Comment 37 • 18 years ago

Btw, there is bug 118379 that talks about a css way of controlling the drop shadow of the popup.

	neil@parkwaycc.co.uk Assignee
	Comment 38 • 18 years ago

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.

	neil@parkwaycc.co.uk Assignee
	Comment 39 • 18 years ago

This actually enables support for transparency, but for best effect should be combined with the following theme changes for SeaMonkey ;-)

	neil@parkwaycc.co.uk Assignee
	Comment 40 • 18 years ago

These changes are not final because this only works on Windows and Linux.

	neil@parkwaycc.co.uk Assignee
	Comment 42 • 18 years ago

>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.

	neil@parkwaycc.co.uk Assignee
	Comment 43 • 18 years ago

Note: only tested on a non-cairo build so far.

	neil@parkwaycc.co.uk Assignee
	Comment 44 • 18 years ago

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.

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 45 • 18 years ago

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.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 46 • 18 years ago

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.

	neil@parkwaycc.co.uk Assignee
	Comment 47 • 18 years ago

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.

	Mike Schroepfer
	Comment 48 • 18 years ago

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.
> 

	neil@parkwaycc.co.uk Assignee
	Comment 49 • 18 years ago

(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.

	Boris Zbarsky [:bzbarsky]
	Comment 50 • 18 years ago

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.

	Mike Schroepfer
	Comment 51 • 18 years ago

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.

	David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)
	Comment 52 • 18 years ago

Do we need a blocking1.9? bug filed on making this chrome-only?

	Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com]
	Comment 53 • 18 years ago

(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?

	Boris Zbarsky [:bzbarsky]
	Comment 54 • 18 years ago

Transparent popups could capture click events, for example.  Including ones outside the browser window, if desired.

	neil@parkwaycc.co.uk Assignee
	Comment 55 • 18 years ago

(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...

	neil@parkwaycc.co.uk Assignee
	Comment 56 • 18 years ago

(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.

	neil@parkwaycc.co.uk Assignee
	Comment 57 • 18 years ago

(In reply to comment #51)
>lack of compelling need for this
Bug 242621

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 58 • 18 years ago

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.

	neil@parkwaycc.co.uk Assignee
	Comment 59 • 18 years ago

Chrome documents are a lot easier to detect, if that's OK with you...

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 60 • 18 years ago

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; } }"

	neil@parkwaycc.co.uk Assignee
	Comment 61 • 18 years ago

I actually added two locals to avoid wrapping any lines at all.

	Boris Zbarsky [:bzbarsky]
	Comment 62 • 18 years ago

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.

	Boris Zbarsky [:bzbarsky]
	Comment 63 • 18 years ago

The point being that simply having a chrome:// URI doesn't mean untrusted content can't touch you.  The principal is what matters.

	neil@parkwaycc.co.uk Assignee
	Comment 64 • 18 years ago

(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.

	Boris Zbarsky [:bzbarsky]
	Comment 66 • 18 years ago

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.

	neil@parkwaycc.co.uk Assignee
	Comment 68 • 18 years ago

Comment on attachment 238544 [details] [diff] [review]
Final complete version

Note: not targeting for Fx2 itself, unless someone really wants bug 242621 fixed.

	Mike Schroepfer
	Comment 69 • 18 years ago

Comment on attachment 238544 [details] [diff] [review]
Final complete version

RC1 is closed.

	Alfred Kayser
	Comment 70 • 18 years ago

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?

	Robert Kaiser
	Comment 71 • 18 years ago

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.

	Alfred Kayser
	Comment 72 • 18 years ago

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.

	Boris Zbarsky [:bzbarsky]
	Comment 73 • 18 years ago

> and the background still fills a rectangular shape

Only for background-image.  background-color works correctly.

	Robert Kaiser
	Comment 74 • 18 years ago

(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) 

	neil@parkwaycc.co.uk Assignee
	Comment 75 • 18 years ago

(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

	Kathleen :Brade
	Comment 76 • 18 years ago

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

	Mike Schroepfer
	Comment 77 • 18 years ago

General criteria for dot releases is security, top crash, and major regressions.     

	Daniel Veditz [:dveditz]
	Comment 78 • 18 years ago

This was fixed on trunk Sept 14

	Daniel Veditz [:dveditz]
	Comment 79 • 18 years ago

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

	neil@parkwaycc.co.uk Assignee
	Comment 80 • 18 years ago

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.

	Daniel Veditz [:dveditz]
	Comment 81 • 18 years ago

Comment on attachment 238544 [details] [diff] [review]
Final complete version

approved for 1.8 branch, a=dveditz for drivers

	neil@parkwaycc.co.uk Assignee
	Comment 82 • 18 years ago

Fix checked in to MOZILLA_1_8_BRANCH

	Rob Campbell [:rc] (:robcee)
	Comment 83 • 18 years ago

verified transparent panning icon in OS X using 2006112906.

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 84 • 18 years ago

Is it possible that this caused bug 364424?
On branch that regressed between 20061128 - 20061130

	Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com]
	Comment 85 • 17 years ago

Do transparent popups work on mac?

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 86 • 17 years ago

No, we don't have transparent window code for Mac.