Closed
Bug 630683
Opened 14 years ago
Closed 7 years ago
A gradient should be added to make the transition from tab to add-ons manager less jarring on OSX
Categories
(Toolkit :: Add-ons Manager, defect)
Toolkit
Add-ons Manager
Tracking
()
RESOLVED
INACTIVE
Tracking | Status | |
---|---|---|
blocking2.0 | --- | - |
People
(Reporter: jboriss, Unassigned)
References
Details
(Keywords: polish)
Attachments
(4 files, 2 obsolete files)
The add-ons manager mockups show that the manager should be a slightly blue color on OSX which extends into the tab it displays in. However, especially as we quickly approach Firefox 4.0, it is probably not possible to color the active tab to match the color of the add-ons manager. So, a slight gradient should be added to aid (and hopefully mask) the transition from the tab color to the color of the background of the manager.
A similar gradient approach was taking in the Windows 7 add-on manager, and the theme looked much more coherent as a result.
Updated•14 years ago
|
blocking2.0: final+ → -
Reporter | ||
Comment 1•14 years ago
|
||
Comment 2•14 years ago
|
||
(In reply to comment #0)
> it is probably not possible to color the
> active tab to match the color of the add-ons manager.
Looks pretty possible to me ;-)
This patch isn't especially invasive or risky in any way; it's just some CSS and image polish, so I think it's a definitive candidate for Firefox 4.
I'm moving the gradient out of the image into the CSS so that we can use a more subtle gradient for the addons manager tab than for normal selected tabs.
This patch is on top of bug 615693.
Comment 3•14 years ago
|
||
Attachment 509604 [details] looks pretty good to me, the consistency of letting the tabs look the same no matter which one you select seems desirable, and the simplicity of the implementation is hard to beat. So I think we should just do that.
Comment 4•14 years ago
|
||
I disagree on points 1 and 2, but don't let that stop you from implementing it.
Assignee: mstange → nobody
Status: ASSIGNED → NEW
Reporter | ||
Comment 5•14 years ago
|
||
(In reply to comment #3)
> Attachment 509604 [details] looks pretty good to me, the consistency of letting the tabs
> look the same no matter which one you select seems desirable, and the
> simplicity of the implementation is hard to beat. So I think we should just do
> that.
Could you post a screenshot from the applied patch? Much appreciated! :)
Comment 6•14 years ago
|
||
Here you are.
The highlight in the top pixel row of the tab is a bit lighter than in the mockups. I did it that way to keep it consistent with the highlight under the rest of the tab bar which we can't manipulate without complicating the code further (at least I can't think of a way at the moment).
Comment 7•14 years ago
|
||
Comment on attachment 511402 [details] [diff] [review]
v1
Oh, this is wrong for tabs-on-bottom mode:
+.tab-background-start[selected="true"],
+.tab-background-middle[selected="true"],
+.tab-background-end[selected="true"] {
+ background-image: -moz-linear-gradient(rgba(255,255,255,0.75), rgba(255,255,255,0.43));
+}
I'll upload a fixed patch if Dão agrees with the approach. Dão, what can I do to convince you? Would you be willing to accept the patch if Boriss said she prefers it over the grey gradient?
Attachment #511402 -
Flags: review?(dao)
Comment 8•14 years ago
|
||
I still think it's a bit inconsistent: for it to work like a real colored tab, it would need to keep a blue shade as a background tab. Anyway, these are the last few days of the Firefox 4 dev cycle, where it's particularly important to keep the scope tight.
Comment 9•14 years ago
|
||
Markus patch looks ridiculously amazing and I haven’t seen a designer yet who’d favor the other variant over that. Please do it this way, it’s a huge polish win for the addons manager.
Reporter | ||
Comment 10•14 years ago
|
||
(In reply to comment #6)
> Created attachment 512757 [details]
> screenshot of patch
>
> Here you are.
>
> The highlight in the top pixel row of the tab is a bit lighter than in the
> mockups. I did it that way to keep it consistent with the highlight under the
> rest of the tab bar which we can't manipulate without complicating the code
> further (at least I can't think of a way at the moment).
Markus, this looks incredible. This is far better than the slightly pessimistic fix this bug proposed. Excellent work. Let's get this sucker reviewed.
Comment 11•14 years ago
|
||
(In reply to comment #8)
> Anyway, these are the
> last few days of the Firefox 4 dev cycle, where it's particularly important to
> keep the scope tight.
I consider this a pretty tightly-scoped patch. I've also extensively tested this patch and haven't found any problems. (I've tested all combinations of: active / inactive window, tabs on top / on bottom, as normal tabs / app tabs, in LTR / RTL mode, with / without lightweight theming, and with / without bug 615693.)
Attachment #511402 -
Attachment is obsolete: true
Attachment #513867 -
Flags: review?(dao)
Comment 12•14 years ago
|
||
Getting these combinations right isn't enough. Extensions can hook into XULBrowserWindow's inContentWhitelist / hideChromeForLocation and there are plans to hide toolbars for app tabs.
Reporter | ||
Comment 13•14 years ago
|
||
(In reply to comment #12)
> Getting these combinations right isn't enough. Extensions can hook into
> XULBrowserWindow's inContentWhitelist / hideChromeForLocation and there are
> plans to hide toolbars for app tabs.
How do those future plans effect the proposed solution of coloring the tab (via Markus' patch)?
Comment 14•14 years ago
|
||
The patch doesn't differentiate between such cases, it just assumes that toolbars being hidden means we need a blue tab.
Updated•14 years ago
|
Attachment #513867 -
Flags: review?(dao) → review-
Reporter | ||
Comment 15•14 years ago
|
||
(In reply to comment #14)
> The patch doesn't differentiate between such cases, it just assumes that
> toolbars being hidden means we need a blue tab.
Hmm, clearly not a permanent solution. Is there a way we can improve the patch by differentiating the add-on manager from other hidden toolbars?
Incidentally, I think that the add-on manager is the only toolbar *we* hide in Firefox 4, since app tabs are no longer hiding them. If an extension hid a menu, would it also turn blue? A temporary solution isn't awesome, but perhaps it fixes the problem in the short term and a better solution can take its place when we hide more toolbars.
Reporter | ||
Comment 16•14 years ago
|
||
After thinking about this problem awhile and discussing it with the rest of the UX team, I'm recommending we ship this patch as is. We'll definitely revisit the issue Dao pointed out in a future release, but for Firefox 4 this is a great solution that solves this problem without creating drawbacks. Dao, as long as the patch works, can we get your r+?
Reporter | ||
Updated•14 years ago
|
Attachment #513867 -
Flags: review- → review?(dao)
Comment 17•14 years ago
|
||
(In reply to comment #15)
> Incidentally, I think that the add-on manager is the only toolbar *we* hide in
> Firefox 4, since app tabs are no longer hiding them. If an extension hid a
> menu, would it also turn blue?
Yes, it would.
Comment 18•14 years ago
|
||
I would like to say that some extensions are indeed already using the infrastructure for hiding chrome, or at least mine is and it would look very out of place if it received this appearance. I hope this patch can be made so that it affects only the Add-on Manager.
Comment 19•14 years ago
|
||
Adam: What's the name of your extension?
Comment 20•14 years ago
|
||
Brief. Right now you need to flip extensions.brief.hideChrome and restart, but I was planning to make it the default in the next version.
Reporter | ||
Comment 21•14 years ago
|
||
(In reply to comment #20)
> Brief. Right now you need to flip extensions.brief.hideChrome and restart, but
> I was planning to make it the default in the next version.
Your next version is probably more likely to hit Firefox 5, where we'll revisit this temporary solution and create a fix that doesn't effect add-ons. This is only a band-aid for 4.0.
Comment 22•14 years ago
|
||
Actually, it's coming out within a few weeks. But it doesn't matter, I can live without this feature. I just wanted to let you know there is a real risk of extensions already relying on this, so that you can assess the cost/reward ratio better and make a conscious decision.
Comment 23•14 years ago
|
||
Here's what Brief looks like without and with the fix. To me it looks off either way, and the fix doesn't make it much worse.
Obviously we'll have to adjust the styling when app tabs start to hide the chrome some time in the future, but I don't think it's justified to do that now. (And then the app tab styling will fit well with Brief, too.)
Comment 24•14 years ago
|
||
Attachment #513867 -
Attachment is obsolete: true
Attachment #516241 -
Flags: review?(dao)
Attachment #513867 -
Flags: review?(dao)
Reporter | ||
Comment 25•14 years ago
|
||
(In reply to comment #22)
> Actually, it's coming out within a few weeks. But it doesn't matter, I can live
> without this feature. I just wanted to let you know there is a real risk of
> extensions already relying on this, so that you can assess the cost/reward
> ratio better and make a conscious decision.
Thanks so much for the feedback, Adam - it really helps to know how this affects add-ons. If you don't mind, I'll keep you CC'd to related bugs once we develop a more permanent solution to determine how this can effect related add-ons.
Comment 26•14 years ago
|
||
Is this going to land in Firefox 4?
Comment 27•14 years ago
|
||
Definitely not for Firefox 4.0 final, not sure if it might slip out in a maintenance release.
Comment 28•12 years ago
|
||
Comment on attachment 516241 [details] [diff] [review]
updated to trunk
I already r-'d this earlier. We should just handle this on OS X like we do on Windows.
Attachment #516241 -
Flags: review?(dao) → review-
Comment 29•7 years ago
|
||
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INACTIVE
You need to log in
before you can comment on or make changes to this bug.
Description
•