70798 - Ability to have transparent background on popups

Status: VERIFIED FIXED

(Core :: XUL, enhancement)

Description

[Brian 'netdragon' Bober]

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]

Attachment: Example

Comment 2

[Brian 'netdragon' Bober]

That was what the popup looked like with this css.

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

Comment 3

[Boris Zbarsky [:bzbarsky]]

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

Comment 4

[Brian 'netdragon' Bober]

What is a viewmanager?

Comment 5

[Brian 'netdragon' Bober]

I have the build from 2/22

Comment 6

[Boris Zbarsky [:bzbarsky]]

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]

->pink

Comment 8

[Mike Pinkerton (not reading bugmail)]

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]

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]

Attachment: With the new view manager

Comment 11

[Skewer]

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]

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]

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

dup of bug 40795?

Comment 15

[Brian 'netdragon' Bober]

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]

Attachment: 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]

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]

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]

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 [:bzbarsky]]

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

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

Comment 22

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This can be implemented via the transparent chrome support.

Comment 23

[Martijn Wargers (dead)]

Attachment: 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)]

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

Comment 25

[Martijn Wargers (dead)]

I think it would be the solution for bug 242621.

Comment 26

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 27

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 28

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 29

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 30

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

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

Sure

Comment 32

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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 [e-mail] [e-mail]]]

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

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 [e-mail] [e-mail]]]

(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 [:bzbarsky]]

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

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

Comment 38

[[e-mail]]

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

[[e-mail]]

Attachment: 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

[[e-mail]]

Attachment: Example theme changes

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

Comment 41

[[e-mail]]

Attachment: Round icons to demonstrate transparency

Comment 42

[[e-mail]]

>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

[[e-mail]]

Attachment: trunk layout changes

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

Comment 44

[[e-mail]]

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][[e-mail]]]

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

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

[[e-mail]]

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]

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

[[e-mail]]

(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 [:bzbarsky]]

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]

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-4, no longer working on Mozilla)]

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

Comment 53

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

(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 [:bzbarsky]]

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

Comment 55

[[e-mail]]

(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

[[e-mail]]

(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

[[e-mail]]

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

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

[[e-mail]]

Attachment: 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)]

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

[[e-mail]]

Attachment: Like this?

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

Comment 62

[Boris Zbarsky [:bzbarsky]]

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 [:bzbarsky]]

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

[[e-mail]]

(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

[[e-mail]]

Attachment: Use the docshell type

Comment 66

[Boris Zbarsky [:bzbarsky]]

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

[[e-mail]]

Attachment: Final complete version

Comment 68

[[e-mail]]

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]

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

RC1 is closed.

Comment 70

[Alfred Kayser]

Attachment: 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]

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]

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 [:bzbarsky]]

> and the background still fills a rectangular shape

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

Comment 74

[Robert Kaiser]

(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

[[e-mail]]

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

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]

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

Comment 78

[Daniel Veditz [:dveditz]]

This was fixed on trunk Sept 14

Comment 79

[Daniel Veditz [:dveditz]]

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

[[e-mail]]

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

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

approved for 1.8 branch, a=dveditz for drivers

Comment 82

[[e-mail]]

Fix checked in to MOZILLA_1_8_BRANCH

Comment 83

[Rob Campbell [:rc] (:robcee)]

verified transparent panning icon in OS X using 2006112906.

Comment 84

[Olli Pettay [:smaug][[e-mail]]]

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

Comment 85

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Do transparent popups work on mac?

Comment 86

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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