The default bug view has changed. See this FAQ.

Make the tab view (Panorama) background transparent to reveal glass (if enabled) on Windows

RESOLVED FIXED in Firefox 4.0b11

Status

Firefox Graveyard
Panorama
P3
normal
RESOLVED FIXED
7 years ago
a year ago

People

(Reporter: mitcho, Assigned: fryn)

Tracking

unspecified
Firefox 4.0b11
x86
Windows 7
Dependency tree / graph

Details

Attachments

(3 attachments, 5 obsolete attachments)

*If* the technical issue of showing aero glass in the background of the tab view in Windows is possible (bug 586679), we will need to determine (a) whether it is wise to do so and (b) what that should look like.

Here's a mockup of what this might look like:

http://www.stephenhorlander.com/images/blog-posts/incontent-ui/win7-tabcandy-glass.jpg

and a mockup of what it could look like if we choose not to show glass:

http://www.stephenhorlander.com/images/blog-posts/incontent-ui/win7-tabcandy-textured.jpg
(Reporter)

Comment 1

7 years ago
Requesting blocking.
blocking2.0: --- → ?

Comment 2

7 years ago
Since it was shown to be possible to show glass (bug 586679), I'll take a stab at implementing Michael's mockup, see how it works out in practice.

Comment 3

7 years ago
Thanks, Oliver. That is super useful! Let us know when you've got something. I'd love to be able to release Panorama with glass.

Point of clarification, those mockups were made by the gifted Stephen Horlander.

Comment 4

7 years ago
Well I've been told those mockups are outdated and their concepts already tried and rejected, so progress has stalled on that front. I don't know of any more recent a mockup.

Comment 5

7 years ago
Told by whom? What parts of the mockups are outdated? News to me.

Comment 6

7 years ago
I was informed by Michael and The_8192 on the TC IRC channel that the orphanage bar had been prototyped previously and then discarded as less usable than the current pseudo-group-orphan-tabs approach.

With that out, the main difference I see in the UI is the tab icon (favicon, not the thumb) has a transparent background while clipping the thumb. Since the canvas element seems to have zero support for stenciling of any kind, I have no idea how to implement this.

PS: Looking closely at the mockup, it looks like the background is not transparent when the tab items are in a stack configuration. Is intended, or a mistake?
(Reporter)

Comment 7

7 years ago
The main intent of this bug is to determine whether making the Panorama background glass is indeed a good idea, or if tweaks like making it less translucent, or more textured, etc., would make it look better. This bug was created as a response to such discussion on bug 586679, just for your reference.

The new tab group at the bottom being reconsidered since that mockup was created is immaterial for this discussion here.

Comment 8

7 years ago
Mitcho is exactly right.
Can't block on "determine." If the tabcandy + ux team determines that change IS needed here, this bug should morph to spec that change, and should be renominated for blocking.
blocking2.0: ? → -
(Reporter)

Updated

7 years ago
Priority: -- → P3

Updated

7 years ago
Assignee: nobody → theappleofpineappe
Target Milestone: Firefox 4.0 → Future

Comment 10

7 years ago
Just tried enabling transparency and this is the result on Win7 with a fairly translucent Win7 theme. Since we're not writing anything directly onto the background without a container I don't see any problems with legibility and design-wise it seems a good deal better than the current situation. Ignore the still visible navbar, that's related to another bug. Option #2 looks nice as well, but it seems a little late to try implementing it since it may not be so trivial given that the we would have to overwrite the frame and return it to normal when leaving TabCandy.

I simply added these lines to tabcandy.css

html, body, #bg{ background:transparent; }
#bg{ display:none; }

Comment 11

7 years ago
Created attachment 476641 [details]
Screenshot of translucent TabCandy window on Win7

Comment 12

7 years ago
This is now pretty much BLOCKING Bug #585689, which has issues with platforms that can't do a drawWindow on a window without returning a transparent image. The problem is that we can't capture and lateron draw a "INSERT AERO SHADING HERE" color, so we can't cover the TabCandy BG. If that BG is transparent that's not much of an issue, but if it is there's little to be done since adjusting the margins surround the TabCandy iFrame would be too slow. The only thing left then would be to draw the whole TabCandy iframe into a Canvas for fast clipping.

Comment 13

7 years ago
Oops, wrong Bug, Bug #597713

Comment 14

7 years ago
OK, we chose another route, so this isn't as urgent anymore (the navbar becomes part of the thumbnail).
(Assignee)

Comment 15

6 years ago
Created attachment 497957 [details]
updated screenshot of glassed panorama on win7
Attachment #476641 - Attachment is obsolete: true
(Assignee)

Comment 16

6 years ago
Created attachment 497963 [details] [diff] [review]
patch

Olivier, do you still plan/want to work on this?

I can take it otherwise.

The only change needed follows.
(The rest of the patch is just trailing whitespace removal.)

-#bg {
+#bg:not(:-moz-system-metric(windows-compositor)) {
   background: url("chrome://browser/skin/tabview/grain.png") repeat scroll center top,
               -moz-linear-gradient(center top , #CCD9EA, #C7D5E7) repeat scroll 0 0 transparent;
 }

The screenshot also experiments with changing the tab group background color to white when glassed, but that isn't included in the patch.
I would like us to try this out in the nightly builds for awhile.  It really helps to visually establish the difference between the browser level and the tab level.  With this approach it Tab view feels considerably more like a place in between places.

There is a downside in that the glass will allow the background complexity to bleed through.  But this also has the effect of making the product feel lighter.
(Assignee)

Updated

6 years ago
Assignee: theappleofpineappe → fryn
Summary: Determine how to style the tab view (Panorama) background on Windows, if glass is possible → Make the tab view (Panorama) background transparent to reveal glass (if enabled) on Windows
(Assignee)

Updated

6 years ago
Attachment #497963 - Flags: review?(dao)
(Assignee)

Updated

6 years ago
Keywords: uiwanted
(Assignee)

Updated

6 years ago
Attachment #497963 - Flags: ui-review?(faaborg)
Attachment #497963 - Flags: ui-review?(faaborg) → ui-review+
Comment on attachment 497963 [details] [diff] [review]
patch

What's the effect of this on lightweight themes?
(In reply to comment #15)
> Created attachment 497957 [details]
> updated screenshot of glassed panorama on win7

Would we want to increase the shadow on groups and tabs here too?
Will this have an adverse effect on perf? Also, will it work with the "impostor" technique Sean is using in bug 617454?
Comment on attachment 497963 [details] [diff] [review]
patch

I haven't actually seen it, but I think this is going to look quite unreasonable with a lightweight theme applied, so you'll need to set a background in that case. I'm also somewhat concerned about performance, but roc will know more about that.
Attachment #497963 - Flags: review?(dao) → review-
It's hard to predict perf impact. It might well be OK. Just have to measure it.
>What's the effect of this on lightweight themes?

lightweight themes should eventually be special cased so that they cover the entire window frame.  However, I don't think we are anywhere near being ready for that yet (I believe all of them are currently 3000px x 200px)
This change may make bug 613606 considerably more noticeable.
(In reply to comment #23)
> >What's the effect of this on lightweight themes?
> 
> lightweight themes should eventually be special cased so that they cover the
> entire window frame.  However, I don't think we are anywhere near being ready
> for that yet

Exactly.
(Assignee)

Comment 26

6 years ago
Created attachment 506114 [details] [diff] [review]
patch v2

This addresses personas quite elegantly.
I'll attach a screenshot shortly.
Attachment #497963 - Attachment is obsolete: true
Attachment #506114 - Flags: ui-review?(faaborg)
Attachment #506114 - Flags: review?(dao)
(Assignee)

Comment 27

6 years ago
Created attachment 506115 [details]
screenshot with personas
Attachment #506115 - Flags: ui-review?(faaborg)
(Assignee)

Updated

6 years ago
Attachment #506114 - Flags: ui-review?(faaborg)
Looking good!
Comment on attachment 506115 [details]
screenshot with personas

can we remove the hard edge at the top of the gradient for a smoother transition?  Overall this looks great.
Attachment #506115 - Flags: ui-review?(faaborg) → ui-review+
(In reply to comment #27)
> Created attachment 506115 [details]
> screenshot with personas

Just to be clear: as far as I can tell from this screenshot, there's no actual glass action here... it's just a patch to fix the interaction with the personas? Or is the background actually slightly translucent?
(In reply to comment #30)
> (In reply to comment #27)
> > Created attachment 506115 [details]
> > screenshot with personas
> 
> Just to be clear: as far as I can tell from this screenshot, there's no actual
> glass action here... it's just a patch to fix the interaction with the
> personas? Or is the background actually slightly translucent?

In which case, this patch is actually a win-specific patch for bug 593388 (which would wontfix bug 590378).
>#bg:not(:-moz-system-metric(windows-compositor))

I think this line applies the styling if glass has been disabled, but I'm not entirely sure.
(Assignee)

Comment 33

6 years ago
(In reply to comment #30)
> (In reply to comment #27)
> > Created attachment 506115 [details]
> > screenshot with personas
> 
> Just to be clear: as far as I can tell from this screenshot, there's no actual
> glass action here... it's just a patch to fix the interaction with the
> personas? Or is the background actually slightly translucent?

When a persona is enabled, we don't use glass when in tab view, since it's too difficult to make the persona fade out.

(In reply to comment #29)
> Comment on attachment 506115 [details]
> screenshot with personas
> 
> can we remove the hard edge at the top of the gradient for a smoother
> transition?  Overall this looks great.

I tried, but we'd have to remove the grain texture of the tab view background, and the bottom of the gradient would have to be well above the bottom of the persona, since I couldn't get the background to align perfectly with the top of the persona.
Comment on attachment 506114 [details] [diff] [review]
patch v2

>+                      -moz-linear-gradient(center top, rgba(255,255,255,0), #CCD9EA 200px, #C7D5E7);

Why rgba(255,255,255,0) rather than #CCD9EA with an alpha value of 0?

Where does the 200px number come from? Is this the height that submitted persona headers need to have at a minimum?
(Assignee)

Comment 35

6 years ago
(In reply to comment #34)
> Comment on attachment 506114 [details] [diff] [review]
> patch v2
> 
> >+                      -moz-linear-gradient(center top, rgba(255,255,255,0), #CCD9EA 200px, #C7D5E7);
> 
> Why rgba(255,255,255,0) rather than #CCD9EA with an alpha value of 0?

To avoid more gray transition than necessary when the persona is primarily of a color complementary to #CCD9EA, but I'm fine with changing it, if using #CCD9EA with an alpha of 0 actually looks better.

> Where does the 200px number come from? Is this the height that submitted
> persona headers need to have at a minimum?

AUIU, yes. http://www.getpersonas.com/demo_create
(In reply to comment #35)
> > Where does the 200px number come from? Is this the height that submitted
> > persona headers need to have at a minimum?
> 
> AUIU, yes. http://www.getpersonas.com/demo_create

It says "should be 3000px wide x 200px high", which is vague, but it goes on to say rather clearly that "images over 3000px x 200px will not be approved" (although I suspect a higher but not nearly as wide image would be approved).
(Assignee)

Comment 37

6 years ago
(In reply to comment #36)
> It says "should be 3000px wide x 200px high", which is vague, but it goes on to
> say rather clearly that "images over 3000px x 200px will not be approved"
> (although I suspect a higher but not nearly as wide image would be approved).

Yeah, that does seem to occur. However, since the guideline is to provide a 3000px x 200px image, I don't think we need to guarantee that the transition works perfectly with personas of any shorter height.
Depends on how effective the guideline is. Did you take a shot at wading through the gallery?
(Assignee)

Comment 39

6 years ago
(In reply to comment #38)
> Depends on how effective the guideline is. Did you take a shot at wading
> through the gallery?

I tried a dozen personas in each of the "Up & Coming", "Popular", "Just Added", and "All Personas" sections of getpersonas.com, and all the header images were exactly 200px in height, except one that was over 200px in height.
Comment on attachment 506114 [details] [diff] [review]
patch v2

>+                      -moz-linear-gradient(center top, rgba(255,255,255,0), #CCD9EA 200px, #C7D5E7);

"center top" seems redundant.
Attachment #506114 - Flags: review?(dao) → review+
Frank, can you post a quick screenshot of a profile without a persona, akin to the first screenshot attached over the windows logo?
(Assignee)

Comment 42

6 years ago
Created attachment 506247 [details]
screenshot without personas
Attachment #497957 - Attachment is obsolete: true
(Assignee)

Comment 43

6 years ago
Created attachment 506248 [details] [diff] [review]
patch v3 [r=dao ui-r=faaborg]

(In reply to comment #40)
> Comment on attachment 506114 [details] [diff] [review]
> patch v2
> 
> >+                      -moz-linear-gradient(center top, rgba(255,255,255,0), #CCD9EA 200px, #C7D5E7);
> 
> "center top" seems redundant.

Addressed in v3, and that's the only change made from v2.

(In reply to comment #41)
> Frank, can you post a quick screenshot of a profile without a persona, akin to
> the first screenshot attached over the windows logo?

Created attachment 506247 [details]
screenshot without personas

The screenshot was taken while dragging the cursor to create a new tab group. If you want to change the borders of the action button container while glassed, that can be addressed in a separate bug.
Attachment #506114 - Attachment is obsolete: true
Attachment #506248 - Flags: approval2.0?
(Assignee)

Comment 44

6 years ago
(In reply to comment #42)
> Created attachment 506247 [details]
> screenshot without personas

Oh I just noticed that the screenshot is actually of a glitch of the action button container's right border being visible. Uploading correct screenshot now.
(Assignee)

Comment 45

6 years ago
Created attachment 506250 [details]
screenshot without personas
Attachment #506247 - Attachment is obsolete: true
>approval2.0? 

Note that I would really like this to land so that we can take some screen captures for a panorama video.  While this bug (and the video itself) doesn't block, I think this visual change is significant enough that it really impacts how sleek and modern panorama feels on Windows.  Also makes for some really fantastic press shots (sans windows logo of course :)
Keywords: ux-feedback
Oh, and improves the conceptual model as well (not to lead with a marketing objective over a UX one)
(In reply to comment #45)
> Created attachment 506250 [details]
> screenshot without personas

I'm slightly concerned that the non-personas version here may be too transparent... previously when we discussed this aero glass option, an idea that was floated was to keep the panorama background but to make it 50% opacity or so... Alex, what do you think?

The concern is that if there are a bunch of other windows below Panorama, not the Windows desktop, that Panorama itself would look cluttered and confusing.

Comment 49

6 years ago
(In reply to comment #48)
> The concern is that if there are a bunch of other windows below Panorama, not
> the Windows desktop, that Panorama itself would look cluttered and confusing.

I once tried this via userchrome.css. I thought that it was fine while the window was restored, but it did become confusing when the window was maximised. I think it would be helpful if it did have a 50% opaque background when maximised.
(Assignee)

Comment 50

6 years ago
I just tried to test the maximized view by pressing win+up to maximize the window, but it entered search mode upon pressing the [win] key. Why do we have [win] mapped to panorama search? (Filing a bug shortly if there isn't one already.)
(In reply to comment #50)
> I just tried to test the maximized view by pressing win+up to maximize the
> window, but it entered search mode upon pressing the [win] key. Why do we have
> [win] mapped to panorama search? (Filing a bug shortly if there isn't one
> already.)

This is the first I've heard of that... please file. :/
(Assignee)

Comment 52

6 years ago
(In reply to comment #51)

Filed bug 628165.
Attachment #506248 - Flags: approval2.0? → approval2.0+
(Assignee)

Comment 53

6 years ago
Pushed.

http://hg.mozilla.org/mozilla-central/rev/0fde0139fb6f

Discuss any pixel tweaks as separate followup bugs, not as comments.
Target Milestone: Future → Firefox 4.0b11
(Assignee)

Updated

6 years ago
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Depends on: 628653
(Assignee)

Updated

6 years ago
Blocks: 628653
No longer depends on: 628653
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.