Closed Bug 415443 Opened 16 years ago Closed 16 years ago

Implement attribute to control window shadow from XUL

Categories

(Core :: Widget, defect)

Product:
Core
Component:
Widget
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9.1b2

People

(Reporter: hwaara, Assigned: mstange)

References

Details

Attachments

(5 files, 1 obsolete file)

XUL testcase
716 bytes, application/vnd.mozilla.xul+xml
Details
Example of the smaller hud window shadow
44.96 KB, image/png
Details
Window Shadow Examples
69.95 KB, image/png
Details
Real OS X Shadows
82.78 KB, image/png
Details
Example of XP's menu shadow
24.26 KB, image/png
Details 
When opening a transparent popup window on OS X, we turn shadows off by default for the popup. 

This is mainly because there are potential redrawing problems for the shadows for a window with an animated content area (with the rest of the bounding box being transparent).

However, it seems that some people want to be able to open transparent XUL popup windows with shadows on. In particular the people working on the Firefox 3 mac theme want it. (See bug 307204 comment 106.)

Can we add a new window.open attribute? Or is a mozilla CSS extension the way to go? It's trivial to turn the shadows on in the mac widget code, the question is how the author should specify it from the chrome.
(Sorry, wrong roc CC'd)
Why is it hard to invalidate the shadow when the contents change? Is it just a case of adding code to know when to invalidate the shadow?
the best option might be a new XUL attribute alongside hidechrome.

I think the shadow was being invalidated, but it kind of lagged behind the contents. Might be hard to fix, but if the alpha values of the popup aren't changing, it won't matter.
IIRC, it was Colin who warned me that shadow invalidation for non-rectangular windows was buggy on (some versions?) of OS X.  

Yes, Gecko would need to notify us when the contents of a window change such that the shadow should be updated. I don't know if this is already done in some way that we could figure it out... roc?

In any event, I can see a case for letting XUL authors decide whether shadows should be on or off for windows in general, so maybe these two issues (invalidating shadows and being able to toggle them) should really be two different bugs.
We'd just update the shadow every time we painted the window.
We've had numerous bugs with shadows not invalidating correctly and shadow invalidation being slow in Adium. Try if you want, but I would be really wary.
Taking. I have a patch to get it working using a new XUL attribute on <window> I call window-shadow. 

It doesn't work to set the shadow on-the-fly using element.setAttribute yet though... I'm investigating it.
Assignee: nobody → hwaara
Here's an implementation of a new attribute called "shadow" which can be true/false, on XUL windows. (I changed my mind to call it "shadow" instead of "window-shadow", because <window window-shadow="true"> looks silly.)

It works great to invalidate the shadow on transparent animated windows by the way. I'll attach the testcase I've used to test this.

I've tested:

* Turning shadows off/on dynamically using the DOM
* Setting it explicitly in the code, and making sure it overrides the default then.
Attachment #302437 - Flags: review?
Attachment #302437 - Flags: review? → review?(joshmoz)
Attached file XUL testcase — 

    
    

    
  
On a build with the patch applied, you can test toggling window shadows on/off with the above testcase by running this command in the Error Console:

open('https://bugzilla.mozilla.org/attachment.cgi?id=302438', '', 'chrome')

    
    

    
  
I've posted the patch to the TryServer on request. The TryServer is right now burning, so I'm not sure if it will be queued (and work), but if it does builds will appear here: https://build.mozilla.org/tryserver-builds/

Look for a folder with "bug_415443" in its name.
Summary: Authors need a way to specify shadows on/off for XUL popup windows → Implement attribute to control window shadow from XUL

    
    

    
  
Hi, 
many thanks at Håkan Waara for a test builds with new window shadows possibilities

i try currently the window shadow and it works great - and i can´t see on my system any problem (Mac OS X 10.5)

i would like to have this feature to improve: 

Bug 403158 – Style new bookmark contextual dialog 

Bug 391984 – [10.5] Add roundness to context menus 

and some other

therefore would be a CSS property nice - is there any change to rebuild it to give themes the control over the shadow?

Cheers 

    
    

    
  
Comment on attachment 302437 [details] [diff] [review]
Implement "shadow" attribute on XUL windows/dialogs

> Index: widget/public/nsIWidget.h

This needs an updated iid.

+    
+  // If we're a transparent window, and our contents have changed, we need

Extra spaces above that comment.

+    NS_IMETHOD              GetSizeMode(PRInt32 *aMode);

Why did you add this?

    
    

    
  
(In reply to comment #13)

> +    NS_IMETHOD              GetSizeMode(PRInt32 *aMode);
> 
> Why did you add this?
> 

Sorry, that's old cruft from another patch. It's removed in my tree now.


    
    

    
  


  
The type of shadow that aronnax is interested in using in his theme is actually a lot smaller than the normal OS X window shadow.  Here is an image of a HUD window produced by the finder.  Is there any way to specify the window shadow style?  I've heard previously that Apple hard codes HUD windows and there is no API:

"The only problem is that Apple hasn’t opened the HUD up to developers. In fact, thus far, they’ve reimplemented the style in every app they’ve published that uses it."
http://andymatuschak.org/articles/2006/01/11/making-the-hud-item-1-a-frame-themed-party

    
    

    
  
> The type of shadow that aronnax is interested in using in his theme is actually
> a lot smaller than the normal OS X window shadow. 

Hi, 
this is not the problem - i want a shadow possibility together with rounded corners 
for example (with Alfred Kayser`s Nautipolis theme)
http://www.takebacktheweb.org/themes/stuff/no-shadow-example.png
He use the transparent window code, which makes the rounded corners possible. But without the shadow merge the star menu with the background and this makes the solution in my opinion unusable. 

I want only a possibility (exactly with the same behavior like this XUL solution), but then with the control over CSS properties. 
Could be used for many theme parts and would likely as well the key to fix some Mac OS X 10.5 integration bugs. 

Cheers  



    
    

    
  
The patch isn't going to support shadows for round corners, is it?

    
    

    
  
(In reply to comment #17)
> The patch isn't going to support shadows for round corners, is it?
> 

the XUL testcase  https://bugzilla.mozilla.org/attachment.cgi?id=302438
looks then: 
http://www.takebacktheweb.org/themes/stuff/transparent.png

as far as i see is it possible to add shadows behind images ... and "container" with rounded corners as well - even much better and more options to build stuff like this ;-) 

Cheers 



    
    

    
  
(In reply to comment #17)
> The patch isn't going to support shadows for round corners, is it?

Shadows will work for any shape of the window, including animated windows.

roc, what do you say about comment 12 ; would it make sense to make this a CSS property instead, so theme authors could specify it? I guess window shadows live in the limbo land between "specifying window properties" (regular DOM attributes) and color/design/form stuff that you typically use CSS for.

    
    

    
  
You can make the popup transparent with style, so it seems reasonable to me to control the shadow with style as well. dbaron is the style master though so it's really up to him.

    
    

    
  
dbaron, what do you say about comment 20? It's your decision.

Some theme authors are apparently eager and waiting for this feature, but are worried that it's getting late...

    
    

    
  
Is it acceptable to have a -moz style property that theme authors can use to control whether a transparent popup or window should have a platform-provided shadow?

    
    

    
  
(In reply to comment #22)
> What's the question?
> 
Hi, 
we need an answer, or is still something unclear?

Cheers  


    
    

    
  
I suppose it is, although it seems sort of a shame to have a property that applies to so few elements.  What would the values of the property be?  Is there any existing property that could be used instead?

    
    

    
  
(In reply to comment #25)
> Is
> there any existing property that could be used instead?
> 
No, for sure not 
and it could and would be used then for many elements

Cheers 

    
    

    
  
(In reply to comment #26)
> (In reply to comment #25)
> > Is
> > there any existing property that could be used instead?
> > 
> No, for sure not 

Don't dismiss the suggestion so quickly.  Are you sure it couldn't be done with -moz-appearance, for example?

> and it could and would be used then for many elements

Is another value (and a different default) for the proposed css3 'box-shadow' appropriate here?

    
    

    
  
Hi, 
yes i`m sure that there is nothing available which is good enough and or not a dirty hack to build what i want to build with these new property 

for example: 
https://bugzilla.mozilla.org/show_bug.cgi?id=403158#c11

Cheers 

    
    

    
  
What would you call the property you're proposing, what values would it take, and what would those values do?

    
    

    
  
Hi, 
today is only this possible:
background: transparent;
and i want it with a shadow .. maybe therefore: 
background: transparent-shadow;

"and what would those values do?"
it should activate the solution which Håkan Waara has already build 
(and exactly with the same behavior like this XUL solution)

Cheers 

    
    

    
  
and again:
we need an answer, or is still something unclear?

Cheers  


    
    

    
  
Actually something like -moz-appearance:window-shadow could work. The idea being that the theme rendering of the window element is the shadow of its non-transparent parts.

(In bug 367993 I thought we might use -moz-appearance:window-glass to give transparent windows Vista's Aero Glass background.)

    
    

    
  
-moz-appearance: window-shadow sounds good to me. I'll see if I can whip up a patch this week.

    
    

    
  
One tricky thing is that nsLayoutUtils::FrameHasTransparency assumes that themed elements do not have transparency. So you'll need to change that, adding a check for window-shadow.

    
    

    
  
This isn't a blocker for Firefox 3, but would be a serious nice to have in terms of enabling themers.

(In reply to comment #25)
> I suppose it is, although it seems sort of a shame to have a property that
> applies to so few elements.  

We've got this in a bunch of places for Vista now (tabbrowserbar-toolbox, media-toolbox), so we might want to come up with a better established way of specifying that the element is single-platform only.

That said, I think we definitely *want* to enable better native look and feel, though it might mean figuring out a way to restrict themes to various platforms.
Flags: wanted-next+

    
    

    
  
A cross platform solution to enable and specify shadow for popup's, panels, windows would be very nice indeed. 
Instead of overloading -moz-appearance (as it is also used for other things), why not introduce a '-moz-shadow' to specify the thickness (and color (and offset)) of the shadow?  (Comparable to text-shadow? http://www.w3.org/TR/css3-text/#text-shadow).

    
    

    
  
Hi Alfred,
a -moz-shadow would be as well nice, but even the text-shadow
bug 10713 comes likely only later with "mozilla2.0"

and this solution can be used now 

and it use the system shadow 
and it is exactly what should be used for stuff like popup's, panels, windows 
and a '-moz-shadow' to specify the thickness .. would be there therefore a second class solution 
---

and unfortunately can't Håkan promise, when he had time this bug

When someone else had time for it would it be very helpful.

Cheers  


    
    

    
  
>-moz-appearance: window-shadow sounds good to me. I'll see if I can whip up a
>patch this week.

How does this effect other platforms, like XP or Vista?  It would be great if we could use the native shadow on each platform.

    
    

    
  
I don't have an opinion about whether we should do -moz-shadow: or -moz-appearance: window-shadow, but I'll need to know which before starting work on this bug again.   dbaron, what's your preference?

    
    

    
  
Hi again, 
i don´t care how it will be called, but it should have a default setting for the system shadow. 
Only then can it be smoothly used for theme stuff to receive always the right shadow independent from the system, which are different on Mac OS X 10.4 or 10.5, or the Windows variations and Linux ... 

With additional possibilities for specify closely the thickness, color and offset .. can it be used as well for other special stuff ... and it would be naturally as well nice to have these possibilities.  

Regards

    
    

    
  
Hi, 
David Baron

the usual stuff - an answer would be nice 

Cheers 

    
    

    
  
Could you describe what the property would do?  Is the question I'm supposed to answer now the one in comment 40?

Things like:

(In reply to comment #30)
> it should activate the solution which Håkan Waara has already build 

don't tell me very much unless I spend a considerable amount of time reading or testing his patch.

    
    

    
  
do you need more examples?

Ok, one more:

i want to write instead of 

#identity-popup-container  {
  background: transparent;
}

and the shadow is away (and it is then unusable for countless parts) 

#identity-popup-container  {
  -moz-appearance: window-shadow
}

and then additional - for example: 
 
#identity-popup-container  {
    background-color: #CDCDCD;
    -moz-border-radius-bottomleft: 8px;
    -moz-border-radius-bottomright: 8px;
    -moz-border-radius-topright: 8px;
    -moz-appearance: window-shadow
}

and it will have then a shadow around the border-radius - and there is no other way to receive stuff like this - every other solution is unusable 


Cheers 

    
    

    
  
> Is the question I'm supposed to
> answer now the one in comment 40?

maybe forgotten 

yes yes yesyes yesyesyesyesyesyes 

or another question please .. 

only something what brings us a step ahead - to finish this  - now - and not next year 

Regards 

    
    

    
  
Could you try writing in sentences rather than sentence fragments?  It's very hard to understand your writing.

When I ask what it does, I'd expect a brief statement that answers questions such as:
 * what elements does the property/value apply to?  (toplevel windows?  popups?)
 * what behavior results from the possible values of the property or from the new value?

If you're proposing a value for -moz-appearance, maybe 'shadowed-window' would be a better name, since the values of -moz-appearance are nouns (the thing that the element appears to be).  Even then, though, it doesn't fit particularly well into -moz-appearance, although it is simpler to put it there than to add a new property.  I almost wonder whether just sticking with a presentational attribute might be better for now.

(In reply to comment #45)
> maybe forgotten 
> 
> yes yes yesyes yesyesyesyesyesyes 
> 
> or another question please .. 
> 
> only something what brings us a step ahead - to finish this  - now - and not
> next year 

If this was intended to convey information to me, it failed.  If you're going to act like I have an obligation to answer anything you ask (which I don't), you should at least try to ask clearly.

    
    

    
  
Hi, sorry - I`m only a stupid themer, who knows what he needs to improve themes 
and by the way, only with bad english. And these stupid themer has no idea what you need. 

As said before:
I would like to have this feature to improve: 

Bug 403158 – Style new bookmark contextual dialog (a popup)

Bug 391984 – [10.5] Add roundness to context menus 


And you can call it, if you want:
-moz-appearance: Make-Aronnax-Happy;  
or only "Make-Aronnax-Happy",
or whatever. 

I want only the possibility.


And likely are Alex Faaborg, Håkan Waara or Mike Beltzner the better persons, who knows what you need. Thanks god, that they understand what i want - hopefully ;-)  

Cheers 





    
    

    
  
(In reply to comment #46)
> When I ask what it does, I'd expect a brief statement that answers questions
> such as:
>  * what elements does the property/value apply to?  (toplevel windows? 
> popups?)

Panels, popups, and windows, I think. We'd want to be able to use it to style contextual information as well as to eventually apply to long-living inspector-style windows (think DOM inspector or a detatched Firebug window).

>  * what behavior results from the possible values of the property or from the
> new value?

I think that's up to Hakan. I'm pretty ambivalent about it. I think that the default should mimic platform look and feel, and am not convinced that we need an element which can be tweaked to provide variable thicknesses, blurs, etc. That argues for -moz-appearance: shadowed-window or something.

Alfred points out, though, that it might be useful to have -moz-shadow: default or -moz-shadow: offset px thickness px or something.

> new property.  I almost wonder whether just sticking with a presentational
> attribute might be better for now.

That's why your advice was asked for! :)

    
    

    
  
Hm, going back on what I said in comment 48 ..

Might be best to do this as:

 -moz-shadow: {default | N M}   where N = px offset and M = px thickness, and default is the default values for the OS

    
    

    
  
> -moz-shadow: {default | N M}   where N = px offset and M = px thickness, and
>default is the default values for the OS

Ideally themers could access the native platform shadow, or specify their own.  

    
    

    
  
Hi, 
many thanks for the support 

and by the way, 
this bug is a good example that there is something wrong in the system. 

It is anyway extremely difficult to find the developer time for GUI bugs like this. Very hard soon in the development progress and nearly impossible late in the development progress. 

And we have here a working solution which needs only a tiny change and a developer who want to work on it in his leisure time and although stops the whole progress as a result of .. yes, why? No idea. 
Likely knows it only David Baron.

It is simply beyond my comprehension.
 
Regards 
 

    
    

    
  
So the problem here is that I'm being asked to decide on the correct solution to a problem whose requirements aren't clear.  I'm not in a position to evaluate which of the many suggested requirements are actually important, so I'm really not in a decent position to make a decision.

Whoever does make a decision here should evaluate the importance various requirements and weigh them against the complexity of the proposed solutions (presentational attribute simplest although bad separation of style and not useful to themers, new value for an existing property slightly more complex, new property significantly more complex).  It's not clear to me things here are really requirements, which things would be really useful, and which things would be sort of nice to have but not particularly important.  Asking questions in the bug -- questions directed to whomever is actually designing this feature (although that's not who seems to be answering them) -- hasn't given me any more information.

I'd be happy to provide feedback to a proposal that says "I think we should go with solution X because requirements A and B are important but C isn't really important."  I think adding those adding new features to the platform, which platform developers will need to support forever, should need to consider such things before just diving in.  I think Håkan is probably in the best position to do that, since he's the one working on the patch.

I'm removing myself from the cc: list of this bug because I'm tired of having unreasonable demands (like "please design this feature in the next 1 hour") made of me and insults hurled at me.

The simple answer to the questions you were asking: "Is X acceptable?" is yes (for either a new value of -moz-appearance or a -moz-shadow property), provided that you've given reasonable consideration to the costs and benefits of the alternative.

    
    

    
  
OK, never mind, I guess I'll just try to design it myself:

I prefer a property called -moz-window-shadow (since there's already box-shadow and text-shadow, so we shouldn't just call it shadow).

I'd propose something like the following values:

  none
    The window has no shadow.
  system
    The window has the windowing environment's default window shadow.

The property should not be inherited (and should therefore live in nsCSSUserInterface and nsStyleUIReset).  The default value should match our current behavior (I don't even know what that is).

Are there any OSes where there's a default window shadow for toplevel windows and a different one for popups / dependent windows?  Or any OSes where they both have shadows but they are different styles by default?  If so, additional values would be needed, and this proposal should be ignored.

    
    

    
  
Also, do windowing systems (Vista's UI, Mac OS X UI) normally provide applications control over changing the appearance / size / darkness / etc. of the window shadow, simply disabling/enabling it, or neither?  Are window shadows expected to vary across applications, and, if so, how?  Or are they only supposed to vary between things that behave like windows and things that happen to be windows but behave like parts of a window?

    
    

    
  
(In reply to comment #49)
>  -moz-shadow: {default | N M}   where N = px offset and M = px thickness, and
> default is the default values for the OS

Oh, and I don't actually understand what you mean by "offset" and "thickness" here; I can understand maybe having separate X and Y offsets for a shadow, though.

    
    

    
  
I'd further note that in the future we may want to merge such a property with http://www.w3.org/TR/css3-background/#the-box-shadow once box-shadow's definition solidifies, but given that it is currently in flux I don't think we want to use that now.

    
    

    
  
Finally, I'd note that if you have followup questions for me and I don't answer them, please ping me politely by private email rather than insulting me in the bug.  I get too much email from bugzilla to actually read all of it, so I often miss things.

    
    

    
  
(In reply to comment #53)
> Are there any OSes where there's a default window shadow for toplevel windows
> and a different one for popups / dependent windows?  Or any OSes where they
> both have shadows but they are different styles by default?  If so, additional
> values would be needed, and this proposal should be ignored.

No, this proposal is just fine in that case, as long as we tell the OS what kind of window each toplevel window is, which we need to do anyway.

Pixel-level control over the shadow is total overkill IMHO. I'm not aware of any apps that use that, nor am I aware of any platforms that support it.

So Hakan, go with comment #53.

Aronnax, you are being obnoxious. Please go away.

Everyone should be clear that this cannot go into Firefox 3.

    
    

    
  

      
      
      
      

        Attached image
          
        Window Shadow Examples
        — 
      

    


  
(In reply to comment #54)
> Also, do windowing systems (Vista's UI, Mac OS X UI) normally provide
> applications control over changing the appearance / size / darkness / etc. of
> the window shadow, simply disabling/enabling it, or neither?  Are window
> shadows expected to vary across applications, and, if so, how?  Or are they
> only supposed to vary between things that behave like windows and things that
> happen to be windows but behave like parts of a window?
> 
I honestly can't say how OS X handles control of the window shadow on application level. I have seen applications that are able to toggle it but none that I can think of alter it's appearance.

However I can say that it varies by *type* of window and the state of the window(foreground or background). A normal window has a very large shadow in Leopard but a HUD window has a much smaller shadow. Menus also have smaller shadows which is primarily what I am interested in.

I can't comment on the technical aspects of it but from a design perspective I can illustrate what I am interested in. This may not be the best way to illustrate it but on the far left is the actual implementation with no-shadow(undesirable). In the middle is a simulated look that panels/menus/HUD windows have in OS X with a smaller shadow size(desirable). The far right is a simulated look with the rather huge shadow a default active window has in Leopard (undesirable).

So it would be nice to have some kind of control of the shadow. If that is just a few different types(default and menu) or more refined control(width/strength and positioning). I am fine with either method.

    
    

    
  

      
      
      
      

        Attached image
          
        Real OS X Shadows
        — 
      

    


  
Sorry, I should have posted this first.

Example of actual different types of shadows in OS X. You can see the normal window shadow, an example of the iCal dialog which appears to have the same shadow as menu items and a HUD window which appears different than both.

    
    

    
  
Do you have a list of the different types of window shadows?  (Is there a system API that lets us choose from among that list?)

If there's a list of types of window we can choose from, that suggests that the property ought to have values for those different types.  (Where the lists differ between different OSes, we'd have separate values that did the same thing for at least some of the OSes, so that our list would be able to make all the distinctions made by any of the platforms.  Assuming the lists are reasonably short, anyway, which is what I'd expect.)

What's "HUD"?

That said, Håkan's patch in attachment 302437 [details] [diff] [review] looks like it's just a binary enabled/disabled thing.

That said, a value list like:

  none
    no window shadow
  default
    the default window shadow for the window type

is extensible in the future to take values like:

  toplevel
    the window shadow appropriate for a toplevel window
  menu
    the window shadow appropriate for a popup menu
  etc.

    
    

    
  
(In reply to comment #61)
> Do you have a list of the different types of window shadows?  (Is there a
> system API that lets us choose from among that list?)
> 
I am sorry, I do not. My programming knowledge doesn't extend much beyond CSS, HTML and Javascript. I could try and find out but perhaps someone more knowledgeable than myself has that information readily available?


> What's "HUD"?
> 
"Heads-up Display" :)

Translucent floating windows mostly used for transient operations.


> That said, a value list like:
> 
>   none
>     no window shadow
>   default
>     the default window shadow for the window type
> 
> is extensible in the future to take values like:
> 
>   toplevel
>     the window shadow appropriate for a toplevel window
>   menu
>     the window shadow appropriate for a popup menu
>   etc.
> 
I would find that to be a nice solution. I don't think that refined control over the shadow is necessary but some options would certainly be welcome. I would almost say "needed" for platform integration.

    
    

    
  
(In reply to comment #61)
> Do you have a list of the different types of window shadows?  (Is there a
> system API that lets us choose from among that list?)
> 
The should give all the basics:
http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGWindows/chapter_18_section_2.html#//apple_ref/doc/uid/20000961-TPXREF48



    
    

    
  
In Cocoa you can customize the offset, blur radius and color of window shadows. For more information, see the NSShadow class.

As David points out, the patch posted is just basically a toggle "on"/"off" of whatever the default shadow is for a given window type. 

As a workaround, if you really really want your customized shadow, I guess you can create a transparent window with system shadows off, and add your own "fake shadow" as part of the transparent window. 

I think it sounds most reasonable to start with a toggle, and implement the -moz-shadow: none/system property.

Whenever there's real need (and other platforms have caught up) we can consider extending it to more granularity. 

Also, is this even possible to get into 1.9 / FF3 at this point? 

    
    

    
  
Sorry, I meant to write -moz-window-shadow: above.

    
    

    
  


  
As far as I can tell there is only one type of shadow on XP, shown in the attached file.  I'll try to catalog the different types of Vista shadows tomorrow when I have access to a Vista machine.

    
    

    
  
>evaluate the importance various requirements and weigh them against the
>complexity of the proposed solutions

Since our primary objective with themeing work is to achieve closer visual integration with the platform, I think we should consider accessing the set of system shadows to be a more important than allowing themers to specify a custom window shadow.

However, this set varies by platform: OS X has 3 (window, menu, transparent panel (HUD)), XP has one (menu), Vista has at least two, and Windows 7 could have several as well when it is released.

How do we normally handle a platform specific value list?  The only other recent example I can think of is bug 419383.


    
    

    
  
As it stands with my shadow toggle, it will toggle whatever the default shadow is for the current window type.  Since there's no way in XUL to e.g. create a native HUD, I think it's reasonable that you'd have to fake its shadow as well for now. Let's file follow-up bugs for such granularity of this property.

dbaron / roc: Is there a chance that a fix for this bug would get into 1.9?  

I won't hurry as much with this bug unless it has the possibility to get on the next release train.

    
    

    
  
(In reply to comment #67)
> However, this set varies by platform: OS X has 3 (window, menu, transparent
> panel (HUD)), XP has one (menu), Vista has at least two, and Windows 7 could
> have several as well when it is released.
> 
> How do we normally handle a platform specific value list?  The only other

We have values for any distinctions that are needed.

Using the examples above for OS X and XP (the ones where you said what the values were), you might add three values:  window, menu, and panel, all of which behave the same on XP.  If Vista's distinctions are different then you might introduce values that behave the same on OS X.

    
    

    
  
Here are the shadows on different platforms I have been able to identify so far:

http://people.mozilla.com/~faaborg/files/daf/windowShadows_i2.png

OS X:
-Menu
-Tooltip
-Window (Active and Inactive)
-Transparent panel

XP:
-Menu
-Tooltip (same as menu)

Vista:
-Menu
-Tooltip (same as menu)
-Window (Active and Inactive)
-Window Preview

I don't think this is a complete list yet, as every platform has multiple types of windows.  cc'ing our linux themers to get a some comments on the set of common shadow types on gnome.

    
    

    
  
Not working on this.
Assignee: hwaara → nobody

    
  
Assignee: nobody → mstange

    
    

    
  
Taking.
Status: NEW → ASSIGNED

    
  

        Attachment #302437 -
        Attachment is obsolete: true

        Attachment #302437 -
        Flags: review?(joshmoz)

    
  
Depends on: 450939

    
  
Depends on: 450944

    
    

    
  
Fixed by bug 450939 and bug 450944 on Mac OS X.
The new default is that all windows get a shadow, not just opaque ones. The shadow can be turned off by setting -moz-window-shadow: none; on the window / panel element.

You can't choose between different shadow styles because Mac OS X doesn't give us a way to do implement it. When -moz-window-shadow is implemented on other platforms, the list of -moz-window-shadow values can be extended.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.1b2

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: