Open Bug 367993 Opened 18 years ago Updated 2 years ago

Make Firefox have the Translucent theme like IE7

Categories

(Core :: Web Painting, enhancement)

Product:
Core
Component:
Web Painting
Platform:
x86
Windows Vista
Type:
enhancement

Tracking

()

People

(Reporter: matthaeus123, Unassigned)

References

Details

Attachments

(3 files)

Screen shot of IE7 on vista.
23.32 KB, image/jpeg
Details
Simple test w/ DwmExtendFrameIntoClientArea
86.80 KB, image/png
Details
Screenshot adding a little opacity
128.43 KB, image/png
Details
Firefox should be able to have the translucent toolbar like IE7 and WMP11 do on Vista. This would only apply to computers running the Aero theme for Vista. The translucency should stop and become opaque, when the window is maximized.
Blocks: 333484
No longer blocks: 352420
Themes should also be able to not have the translucent look and be able to cover it with the theme's own background.
I am not sure that this should block Bug 333484.
No longer blocks: 333484
Notice that the top-bar is translucent. And uses the Vista Aero theme to its full advantage.
I was wondering if this would really be a issue with just Firefox or should it be a issue with the core?
Assignee: nobody → roc
Component: OS Integration → Layout: View Rendering
Product: Firefox → Core
QA Contact: os.integration → ian
Target Milestone: Firefox 3 → ---
I loaded up this theme: http://www.deviantart.com/deviation/51924769 Killed the menubar, and changed the theme's Toolbar-Address-Background image to just a solid black bar. I then called DwmExtendFrameIntoClientArea on the firefox window, and I got this. It's not as bad as I thought it would be. It looks like the main thing that has to be done is change how the the way the text in the urlbar is being drawn. IE does some cool alpha transparency effects with hovering over the addressbar/search bar, but those aren't as important. So it looks like if someone would just change the way FF draws the text in the address bar, we could have themes that use extended glass without too much difficulty.
This would be really nice to include.
Agreed, I really hope this isn't too difficult to accomplish and can be done soon.
Most of the stuff in that neowin thread is ignorable, from what I can tell. The reason that the text in the title bar is rendered as white is because it's having the glass effect applied to it -- in this mode, the glass effect is applied by color key, and unless the color key is explicitly set, it defaults to black.
That's what I originally thought, but that's not correct. In that PNG I posted a few comments up, look closely. You'll note that the text in the address bar is red. I set the text color to red, and it's still being rendered as part of the background of the window. I'm not 100% sure, but I think it has to do with when the text is painted.
Also, the Google logo is being subjected to the Aero effect as well in the screenshot I posted.
Don't know if this helps, but adding just a little opacity to elements seems to fix some of the rendering. Here's a screenshot after calling DwmExtendFrameIntoClientArea and with the CSS: #toolbar-menubar, #nav-bar { -moz-appearance: none !important; background-color: black !important; border: none !important; } #urlbar, #searchbar { opacity: .8 !important; } #main-menubar, #main-menubar label { opacity: .999 !important; color: black !important; }
Looks nice. Out of curiosity, where do you call DwmExtendFrameIntoClientArea to make this work? (In reply to comment #12) > #toolbar-menubar, > #nav-bar { > -moz-appearance: none !important; > background-color: black !important; > border: none !important; > } Why specific toolbars? Can't you use toolbar { instead? That way extension toolbars like the Web Developer toolbar will also inherit glass. Do statusbars also generally get glass? If so you could add statusbar to the mix. > #urlbar, > #searchbar { > opacity: .8 !important; > } Why .8? Keep in mind that I'm not a Vista user or Windows user so there may be some interface guideline thingy that I'm missing.
I just had another thought, how will this affect users who don't have glass turned on?
(In reply to comment #13) > Looks nice. Out of curiosity, where do you call DwmExtendFrameIntoClientArea to > make this work? You can call it anytime. When the window is created, but before it's shown is probably the best time. But you can call it anytime after the fact. It's just that after you call it, it will be reset on certain events, like turning the DWM on/off.
>Created an attachment (id=304531) [details] >Screenshot adding a little opacity If the color key appears in the content area does that area turn to glass as well? It was my understanding that is why this is why the color key approach doesn't work, and the only alternative is to specify glass regions at the widget layer, which involves platform changes outside of the scope this release (but definitely in the next release).
Is this going to be the "Surprise Package" in Firefox 3? I sure hope so :-)
(In reply to comment #13) > Why specific toolbars? Can't you use > toolbar { > instead? That way extension toolbars like the Web Developer toolbar will also > inherit glass. Do statusbars also generally get glass? If so you could add > statusbar to the mix. Well, if this is trying to work something like IE7, it should only be applied to the main toolbar - additional toolbars in IE7 do not take glass, nor does the statusbar.
(In reply to comment #18) > (In reply to comment #13) > > Why specific toolbars? Can't you use > > toolbar { > > instead? That way extension toolbars like the Web Developer toolbar will also > > inherit glass. Do statusbars also generally get glass? If so you could add > > statusbar to the mix. > Well, if this is trying to work something like IE7, it should only be applied > to the main toolbar - additional toolbars in IE7 do not take glass, nor does > the statusbar. However that's not to say any implementation of it should not be made flexible for the person making a skin.
>Looks nice. Out of curiosity, where do you call DwmExtendFrameIntoClientArea to >make this work? Could everyone quickly provide very specific and complete information on how they are achieving Aero glass functionality. The code freeze for beta 4 is on Tuesday, and that is our last chance to make major changes to the appearance of Firefox so we can still generate some feedback before RC1. If anyone has a solution that we overlooked that doesn't suffer from the problems of color key areas in the content area turning to glass, and isn't as involved as specifying areas of glass at the widget layer (bug 418454), please tell us exactly what you figured out as soon as you possibly can. I really want us to support glass, but we need to understand your approach.
>Looks nice. Out of curiosity, where do you call DwmExtendFrameIntoClientArea to make this work? Its just called from an extension via the onload event. My C++/XPCOM abilities suck, and I had a horrible time getting the right HWND to draw on. I'd feel kinda nervous posting it for anyone to look at. > Why specific toolbars? Can't you use toolbar instead? That way extension > toolbars like the Web Developer toolbar will also inherit glass. Do > statusbars also generally get glass? If so you could add statusbar to the mix. > > Why .8? Sorry. I was just posting the code I used for the screenshot, which had some old userchrome I wrote applied. In IE7 the urlbar is semitransparent until you hover it, so I think that's what it was trying to do. Its not meant to be a recommendation for the theme. And as was said, its probably best as an opt in thing for toolbars/widgets, not the default. >If the color key appears in the content area does that area turn to glass as >well? It was my understanding that is why this is why the color key approach >doesn't work, and the only alternative is to specify glass regions at the >widget layer, which involves platform changes outside of the scope this release >(but definitely in the next release). DwmExtendFrameIntoClientArea takes in a margins object which tells it how far to extend the frame on the top/bottom/left/right. There's no reason for the glass effect to ever spill into the content area unless you want it to. Even if just small regions are drawn as glass via DwmEnableBlurBehindWindow, you still have to deal with the color key thing though, which forces you to deal with the order in which objects are drawn. For instance, MS uses DwmEnableBlurBehindWindow here in this example to make an entire window transparent: http://msdn2.microsoft.com/en-us/library/aa969537(VS.85).aspx and still has the menu problem. Setting the opacity probably just delays drawing so that it happens after DwmExtendFrameIntoClientArea is called, and hence the text isn't made transparent. Alex - to do this correctly you'd also want to use some of MS's font rendering stuff so that toolbarbutton labels and menu text were drawn with a glow behind them. Getting it into the core "correctly" is probably a lot of work involving changes in both Gecko and Cairo. For the time being, its probably better shipped as an extension/theme combo for people to play with. Not a core feature.
>I'd feel kinda nervous posting it for anyone to look at. Don't worry about that, facilitating a discussion with some of our platform developers about if there is a way for us to get glass support landed is more important than pride :) >Setting the opacity probably just delays >drawing so that it happens after DwmExtendFrameIntoClientArea is called, and >hence the text isn't made transparent. Yeah, that's definitely a bit scary to rely on. >Alex - to do this correctly you'd also want to use some of MS's font rendering >stuff so that toolbarbutton labels and menu text were drawn with a glow behind >them. I personally think neither of these are big enough issues to drop the support entirely. To follow the layout of other applications we would want the menu bar to appear using the normal appearance under the navigation toolbar. So the order from top to bottom would be Navigation toolbar (glass), menu bar, bookmarks toolbar, tabstrip. In terms of the button text, this is also not standard for vista applications, so I have no problem cutting support for it. Ideally we would turn all glass effects off if the user customized the layout of their toolbars or wanted to turn on button labels.
Quick update from a call with beltzner and mconnor: there is really no way we could take this change for beta 4. However, if we get a working implementation very soon some of us are interested in potentially considering a beta 5 proposing that we possibly delay the schedule so that we can include support for glass in this release. Additional thing we need to consider: -what happens if the user has a larger font in the location bar, do we calculate the height of the navigation toolbar or would that value need to be hard coded?
In the implementation I have now the height of the toolbar is calculated when the compositor calls are made. That's easy, but again a good implementation would need to watch for changes to the toolbar size (or mode) in order to keep the glass where it belongs.
I guess the reason setting opacity works is that we end up with a color for the text that isn't exactly black, so the color-key stuff doesn't make it glassy. I can't find the docs that describe how the color-key works. Color-key is a fragile approach, I don't know why they didn't use window alpha for this. Basically there'll always be a risk of making a change that unexpectedly causes content to disappear into the glass. Even apart from the color-key issues, using DwmExtendFrameIntoClientArea would be complicated. We can't hardcode the size, we have to define a XUL API that lets us specify what can be glassy, and drive support for that from layout down to widget so we can set the correct area. That has to handle dynamic updates if toolbars get hidden or shown, even if we try to simplify things by just disabling glass effects. "Disable glass effects if anything changes" is actually pretty hard to implement because so much can be changed e.g. in the presence of extensions. I'm stunned we're considering slipping the release for this. I think that would be crazy.
Well, we shouldn't rush Fx3 out of the doors just to get it out. I think most people would gladly accept another beta for UI and polish.
> I can't find the docs that describe how the color-key works. Color-key is a > fragile approach, I don't know why they didn't use window alpha for this. Yeah, MS doesn't seem to describe it much. I did find some info about it here: http://weblogs.asp.net/kennykerr/archive/2006/08/10/Windows-Vista-for-Developers-_1320_-Part-3-_1320_-The-Desktop-Window-Manager.aspx
This isn't polish, it's a new feature that shouldn't be rushed. Forbidding text on the main nav bar scares me the most right now. Probably better for 1.9.1.
Oh thanks! That makes it clear. They actually are using window alpha values and the "color-key" effect is just an accident of Windows GDI. This means just calling DwmExtendFrameIntoClientArea and continuing to use our drawing code as if the window was a regular opaque window would be *extremely* dodgy. The right way to do this would be to use DwmExtendFrameIntoClientArea to make the whole window glass, and then enable our transparent window support and make the parts of the window you want to be glassy transparent. Only problem is, there's a major performance hit for this and because we don't support content IFRAMEs in translucent chrome windows, you wouldn't be able to view Web content. Oh well. Post-1.9, the Compositor work will fix that bug and make this a lot more feasible. (In reply to comment #26) > Well, we shouldn't rush Fx3 out of the doors just to get it out. I think most > people would gladly accept another beta for UI and polish. Why would the 90% of users who are not on Vista care? Maybe there are huge UI and polish problems that require another beta on their own, if so you'd better alert the release drivers since I don't think we're aware of them. And what Dao said, this is not a polish issue, this is a major new feature. We absolutely should rush Fx3 out of the door, because it's already a gigantic improvement over Fx2. Whoever these "some of us" are who are considering a beta5 for this, please step up so I can flame you.
>Whoever these "some of us" are who are considering a >beta5 for this, please step up so I can flame you. To be fair I said consider proposing. 90% of our users won't care, but nearly 100% of the PC tech journalists are running Vista. For an example of how our vista theme is being reviewed listen to the comments at 33:44 in this podcast: http://www.podtrac.com/pts/redirect.mp3/twit.cachefly.net/WW-049.mp3 Not getting hit with review comments like that is in my opinion totally worth a 1 or 2 week delay, and crippling some features on Vista (like text in the navigation toolbar). Ok, you can flame me now.
(In reply to comment #30) > Not getting hit with review comments like that is in my opinion totally worth a > 1 or 2 week delay, and crippling some features on Vista (like text in the > navigation toolbar). > > Ok, you can flame me now. > No flames here, I couldn't agree more. While a majority of FF users may not be on Vista, more and more home users are using it as they purchase new machines, and that number is only going to increase over the next year. Better that an extra week is spent now so that the feature is in FF3.0 final, and it can be mentioned in the reviews, etc, rather than adding it later, after the initial excitement from the release of 3 is long gone. While it may not seem like a huge thing to a lot of us, I think many might be surprised by the huge positive reaction it would receive if it's in there.
Hang on Alex. You were showing mockups of the glassy theme in October and this bug has had no activity until February? What happened here?
(In reply to comment #32) > Hang on Alex. You were showing mockups of the glassy theme in October and this > bug has had no activity until February? What happened here? A bunch of Alphas and Betas and a bunch of different work. As we start to get more users we're going to start to see more interest from people in helping us with fit and finish. That's not surprising at all. I don't think it's right to call people out just because they've arrived at the table a little late in our shipping schedule :) To clarify Alex's comment, the people who are "potentially considering" another beta do not include myself nor mconnor. As stated at all project meetings, our goal is to get the browser into a shippable state as soon as possible and get the release out. I also agree with Dao in comment 28; changes of this magnitude are likely to have effects that are hard to predict, and we can't rush into them willy-nilly. What I want to make clear, though, is that saying "we're not gonna do it for beta" or "we're not gonna slip release for this" is not tantamount to saying "we're not interested in this". I appreciate the work and investigation (both from Wesley and from Roc) and insight into what needs to happen to make this work right, as it helps us scope and understand how to make the fix. I'm adding "wanted1.9+" to this, as I think that's now clear. I'm also going to mark this "blocking1.9-" as I think that's now equally clear.
Flags: wanted1.9+
Flags: blocking1.9-
It might actually be possible to do this without much pain. It sounds like DwmExtendFrameIntoClientArea makes the Vista compositing window manager start paying attention to the alpha values drawn into the window *without* having to enable layered windows. If that's true, we could treat glass-mode as a different kind of transparency-mode: -- Call DwmExtendFrameIntoClientArea to cover the whole window area (or possibly just the area above all child windows, if this interacts poorly with child windows, although it would be much simpler if we could avoid this) -- During painting of a glassy window, do a cairo push_group(CONTENT_COLOR_ALPHA) around the painting. So cairo will blit back full RGBA data. That might just work, although there would be a performance hit. One way to expose this would be to support a new nsITheme value which lets you do "background:transparent; -moz-appearance:glass" on a document root element. You might also want a new nsILookAndFeel CSS pseudo selector atom so that style rules can depend on whether the platform is supporting glass or not. More useful info here: http://blogs.msdn.com/greg_schechter/archive/2006/09/14/753605.aspx although this all seems really poorly documented, which adds to the risk.
It would be pretty easy to do an experiment to see if that approach would work. I might take a look on Monday.
(In reply to comment #34) > You might also want a new nsILookAndFeel CSS pseudo selector atom so that style > rules can depend on whether the platform is supporting glass or not. And whether it's enabled or not, right? Generally (applies other nsILookAndFeel stuff as well), doesn't an @ rule make more sense than a pseudo class on a specific element?
(In reply to comment #36) > And whether it's enabled or not, right? Yes. > Generally (applies other nsILookAndFeel stuff as well), doesn't an @ rule make > more sense than a pseudo class on a specific element? It's more work to implement. -moz-system-metric is really easy to support.
(In reply to comment #34) > -- During painting of a glassy window, do a cairo > push_group(CONTENT_COLOR_ALPHA) around the painting. So cairo will blit back > full RGBA data. > That might just work, although there would be a performance hit. Not much of one, I don't think; if we're already on vista, there isn't much difference between a DIB and a DDB. The DIB (even with ARGB) might even be faster. Normally we use CONTENT_COLOR and just DDB's for double buffering (note that we already do a PushGroup around all painting, so this would be easy to do). > One way to expose this would be to support a new nsITheme value which lets you > do "background:transparent; -moz-appearance:glass" on a document root element. > You might also want a new nsILookAndFeel CSS pseudo selector atom so that style > rules can depend on whether the platform is supporting glass or not. There are a number of Vista Aero native theme styles that have 'Composited' in the subclass name; these are generally partially translucent versions of the main fully opaque style. We could teach our theme code to pull the Composited versions if compositing is turned on. But this is overall pretty risky, especially this late.
Hi, I thought a link to a thread on the forums would be helpful. You may want to get in contact with Canyonero there. He has managed to get some code to call on vista transparency. http://i6.photobucket.com/albums/y235/PacMan2000/Vista2.png http://forums.mozillazine.org/viewtopic.php?t=630212&postdays=0&postorder=asc&postsperpage=15&start=0
(In reply to comment #2) > I am not sure that this should block Bug 333484. > I agree, to be honest, I much prefer the IE glassy look to firefox's grey toolbar. As as a few have already demonstrated, it's not even that trivial to implement.
The problem with the control transparency quirkiness is that GDI is not aware of transparency therefore the Black used in GDI is confused with the Transparency Key that the DWM picks up. Historically, in early builds of Vista there was a work around which allowed you to tweak the Transparency Key that the DWM used. Microsoft (for god knows what reason) removed this work around which caused some headaches come RTM. Admittedly, I have not played with the DWM API as much as I used to but according to a few articles I've read there are a few solutions for this problem. The most informational one I can point you to is: http://weblogs.asp.net/kennykerr/archive/2007/01/23/controls-and-the-desktop-window-manager.aspx I'm not sure about the inner workings of Firefox, so the solution proposed there may not be very practical and maybe an alternate solution is possible. One thing to be aware of however, is the fact that the DWM APIs are only availible under Vista (Duh) and that the user can change the state of the DWM at any time. I think there's a Window Message which notifies you of a DWM change, at which point you test to see if it's enabled and if it is you just call the Extend to Client Area API again. Cheers.
Just a question. I've done a little digging, and Vista provides a toolbar style, NavBar::Rebar that is used when compositing is disabled (with the Vista Basic theme) to give a "unified" appearance. In fact, there are a whole bunch of toolbar styles associated with this (trying to do this from memory so these might be wrong): NavBar::Rebar NavBarComposited::Rebar NavBarInactive::Rebar NavBarInactiveComposited::Rebar NavBarMaximized::Rebar etc. etc. When/if this is ever implemented Gecko needs to fall back to these styles when compositing is disabled. If they were wanted now, I can make a new bug and write a patch to put them in using the same css methods used for Media::Rebar, but it seems like a better implementation would just have a navbar-toolbox appearance keyword and would pick the correct style based on whether composition was enabled and on the window state. Anyway, is there any interest in just having them for FF3, or is it better to wait until glass is available before integrating them?
Flags: wanted1.9-
Flags: wanted1.9+
Flags: wanted-next+
Heads up for you guys, someone has successfully implemented glass on Firefox 3. It needs some work and an accompanying icon theme etc ( the blue vista icons dont look good on a blue sky background picture ) but the idea and implementation works well. http://www.neowin.net/forum/index.php?showtopic=632112
Awesome! The Firefox team should really try to add this before Firefox 3 goes final. I'd love to see it be added.
That's cool, but RC1 is not the time to add alpha-quality code to the product.
With all do respect, some of us aren't running the fastest machines out there possible. I think we should keep it as it is, and hold off on this till atleast Firefox 4. Aero is already slow enough as it is, I don't think we need Firefox adding to that category. =)
then disable the Aero -- no problem there. If you use Aero, then a semi-transparent toolbar shouldn't slow the system down much...
QA Contact: ian → layout.view-rendering
Component: Layout: View Rendering → Layout: Web Painting
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: