Ability to have transparent background on popups

VERIFIED FIXED in mozilla1.9alpha1

Status

()

Core
XUL
--
enhancement
VERIFIED FIXED
17 years ago
9 years ago

People

(Reporter: Brian 'netdragon' Bober, Assigned: neil@parkwaycc.co.uk)

Tracking

(Depends on: 2 bugs, {verified1.8.1.1})

Trunk
mozilla1.9alpha1
verified1.8.1.1
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.8.1.1 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(10 attachments, 3 obsolete attachments)

83.57 KB, image/jpeg
Details
2.68 KB, image/gif
Details
144.69 KB, image/jpeg
Details
909 bytes, application/vnd.mozilla.xul+xml
Details
1.38 KB, patch
Details | Diff | Splinter Review
2.31 KB, application/zip
Details
5.99 KB, patch
roc
: review+
Details | Diff | Splinter Review
1.01 KB, patch
Details | Diff | Splinter Review
2.20 KB, patch
roc
: review+
Mike Schroepfer
: approval1.8.1-
Details | Diff | Splinter Review
27.70 KB, image/jpeg
Details
(Reporter)

Description

17 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.
(Reporter)

Comment 1

17 years ago
Created attachment 26707 [details]
Example
(Reporter)

Comment 2

17 years ago
That was what the popup looked like with this css.

popup.panning-class
{
    	border-style: none;
    	background-color: transparent;
}
Brian, is this with the old viewmanager or with the new one?
(Reporter)

Comment 4

17 years ago
What is a viewmanager?
(Reporter)

Comment 5

17 years ago
I have the build from 2/22
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

17 years ago
->pink
Assignee: trudelle → pinkerton
Status: UNCONFIRMED → NEW
Ever confirmed: true
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?
Depends on: 71112
Target Milestone: --- → Future
(Reporter)

Comment 9

17 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.
(Reporter)

Comment 10

17 years ago
Created attachment 26975 [details]
With the new view manager

Comment 11

16 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).
(Reporter)

Comment 12

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

Comment 13

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

Comment 14

16 years ago
dup of bug 40795?
(Reporter)

Comment 15

16 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

(Reporter)

Comment 16

16 years ago
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.
(Reporter)

Comment 17

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

(Reporter)

Comment 18

16 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.
(Reporter)

Comment 19

16 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.
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.
Depends on: 40795

Updated

15 years ago
Summary: [RFE] Ability to have transparent background on popups → Ability to have transparent background on popups
Blocks: 92748
*** Bug 92748 has been marked as a duplicate of this bug. ***
This can be implemented via the transparent chrome support.
Assignee: pinkerton → roc
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.
This is not supposed to work. Additional work needs to be done. It's probably
not hard...
I think it would be the solution for bug 242621.
Yeah. Something to work on for 1.9. Have a go, Martijn :-).
http://lxr.mozilla.org/seamonkey/source/layout/generic/nsContainerFrame.cpp#543
Assignee: roc → cbiesinger
Target Milestone: Future → mozilla1.9alpha
*** Bug 308818 has been marked as a duplicate of this bug. ***
Blocks: 325407
-> default owner, I'm clearly not working on this
Assignee: cbiesinger → nobody
QA Contact: jrgmorrison → xptoolkit.xul
Is there someone who could help me write this if nobody else will do it?
Sure
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
(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)
You may also need to set -moz-appearance:none on the popup to disable any native theme background painting.
(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.
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.
Btw, there is bug 118379 that talks about a css way of controlling the drop shadow of the popup.
(Assignee)

Comment 38

11 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.
(Assignee)

Comment 39

11 years ago
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 ;-)
Attachment #236567 - Flags: superreview?(roc)
Attachment #236567 - Flags: review?(roc)
(Assignee)

Comment 40

11 years ago
Created attachment 236568 [details] [diff] [review]
Example theme changes

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

Comment 41

11 years ago
Created attachment 236569 [details]
Round icons to demonstrate transparency
(Assignee)

Comment 42

11 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.
(Assignee)

Comment 43

11 years ago
Created attachment 236661 [details] [diff] [review]
trunk layout changes

Note: only tested on a non-cairo build so far.
Attachment #236661 - Flags: superreview?(roc)
Attachment #236661 - Flags: review?(roc)
Attachment #236661 - Flags: superreview?(roc)
Attachment #236661 - Flags: superreview+
Attachment #236661 - Flags: review?(roc)
Attachment #236661 - Flags: review+
Attachment #236567 - Flags: superreview?(roc)
Attachment #236567 - Flags: superreview+
Attachment #236567 - Flags: review?(roc)
Attachment #236567 - Flags: review+
(Assignee)

Comment 44

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

Comment 45

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

Updated

11 years ago
Blocks: 351716

Updated

11 years ago
No longer blocks: 351716
Depends on: 351716
(Assignee)

Updated

11 years ago
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
(Assignee)

Comment 47

11 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.
Attachment #236567 - Flags: approval1.8.1?

Comment 48

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

(Assignee)

Comment 49

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

11 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.
Attachment #236567 - Flags: approval1.8.1? → approval1.8.1-
Do we need a blocking1.9? bug filed on making this chrome-only?
(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?
Transparent popups could capture click events, for example.  Including ones outside the browser window, if desired.
(Assignee)

Comment 55

11 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...
(Assignee)

Comment 56

11 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.
(Assignee)

Comment 57

11 years ago
(In reply to comment #51)
>lack of compelling need for this
Bug 242621
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.
(Assignee)

Comment 59

11 years ago
Created attachment 238174 [details] [diff] [review]
Permit chrome documents only

Chrome documents are a lot easier to detect, if that's OK with you...
Assignee: nobody → neil
Status: RESOLVED → ASSIGNED
Attachment #238174 - Flags: superreview?(roc)
Attachment #238174 - Flags: review?(roc)
Resolution: FIXED → ---
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; } }"
Attachment #238174 - Flags: superreview?(roc)
Attachment #238174 - Flags: superreview+
Attachment #238174 - Flags: review?(roc)
Attachment #238174 - Flags: review+
(Assignee)

Comment 61

11 years ago
Created attachment 238180 [details] [diff] [review]
Like this?

I actually added two locals to avoid wrapping any lines at all.
Attachment #236567 - Attachment is obsolete: true
Attachment #238180 - Flags: superreview?(roc)
Attachment #238180 - Flags: review?(roc)
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.
The point being that simply having a chrome:// URI doesn't mean untrusted content can't touch you.  The principal is what matters.
(Assignee)

Comment 64

11 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.
(Assignee)

Comment 65

11 years ago
Created attachment 238315 [details] [diff] [review]
Use the docshell type
Attachment #238174 - Attachment is obsolete: true
Attachment #238315 - Flags: superreview?(bzbarsky)
Attachment #238315 - Flags: review?(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.
Attachment #238315 - Flags: superreview?(bzbarsky)
Attachment #238315 - Flags: superreview+
Attachment #238315 - Flags: review?(bzbarsky)
Attachment #238315 - Flags: review+
(Assignee)

Comment 67

11 years ago
Created attachment 238544 [details] [diff] [review]
Final complete version
Attachment #238180 - Attachment is obsolete: true
Attachment #238180 - Flags: superreview?(roc)
Attachment #238180 - Flags: review?(roc)
Attachment #238544 - Flags: superreview?(roc)
Attachment #238544 - Flags: review?(roc)
Attachment #238544 - Flags: superreview?(roc)
Attachment #238544 - Flags: superreview+
Attachment #238544 - Flags: review?(roc)
Attachment #238544 - Flags: review+
(Assignee)

Comment 68

11 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.
Attachment #238544 - Flags: approval1.8.1?

Comment 69

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

RC1 is closed.
Attachment #238544 - Flags: approval1.8.1? → approval1.8.1-

Comment 70

11 years ago
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

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

Comment 72

11 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.
> and the background still fills a rectangular shape

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

Comment 74

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

Comment 75

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

Updated

11 years ago
Attachment #238544 - Flags: approval1.8.1.1?

Comment 76

11 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
Flags: blocking1.8.1.1?

Comment 77

11 years ago
General criteria for dot releases is security, top crash, and major regressions.     
Flags: blocking1.8.1.1? → blocking1.8.1.1-
This was fixed on trunk Sept 14
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago11 years ago
Flags: wanted1.8.1.x?
Resolution: --- → FIXED
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
Attachment #238544 - Flags: approval1.8.1.1? → approval1.8.1.1-
(Assignee)

Comment 80

11 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.
Attachment #238544 - Flags: approval1.8.1.1- → approval1.8.1.1?
Comment on attachment 238544 [details] [diff] [review]
Final complete version

approved for 1.8 branch, a=dveditz for drivers
Attachment #238544 - Flags: approval1.8.1.1? → approval1.8.1.1+
(Assignee)

Comment 82

11 years ago
Fix checked in to MOZILLA_1_8_BRANCH
Keywords: fixed1.8.1.1
Status: RESOLVED → VERIFIED
verified transparent panning icon in OS X using 2006112906.
Keywords: verified1.8.1.1
Flags: wanted1.8.1.x?

Updated

11 years ago
Keywords: fixed1.8.1.1

Comment 84

11 years ago
Is it possible that this caused bug 364424?
On branch that regressed between 20061128 - 20061130
Depends on: 364424
Blocks: 242621
Do transparent popups work on mac?
No, we don't have transparent window code for Mac.
Blocks: 374357
No longer blocks: 374357
Blocks: 307204

Updated

9 years ago
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: xptoolkit.xul → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.