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)

defect
Not set
normal

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.
blocking2.0: final+ → -
Attached patch v1 (obsolete) — Splinter Review
(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.
Assignee: nobody → mstange
Status: NEW → ASSIGNED
Attachment #511402 - Flags: review?(dao)
Depends on: 615693
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.
I disagree on points 1 and 2, but don't let that stop you from implementing it.
Assignee: mstange → nobody
Status: ASSIGNED → NEW
(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! :)
Attached image 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).
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)
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.
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.
(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.
Attached patch v2 (obsolete) — Splinter Review
(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)
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.
(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)?
The patch doesn't differentiate between such cases, it just assumes that toolbars being hidden means we need a blue tab.
Attachment #513867 - Flags: review?(dao) → review-
(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.
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+?
Attachment #513867 - Flags: review- → review?(dao)
(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.
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.
Adam: What's the name of your extension?
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.
(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.
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.
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.)
Attached patch updated to trunkSplinter Review
Attachment #513867 - Attachment is obsolete: true
Attachment #516241 - Flags: review?(dao)
Attachment #513867 - Flags: review?(dao)
(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.
Is this going to land in Firefox 4?
Definitely not for Firefox 4.0 final, not sure if it might slip out in a maintenance release.
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-
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.

Attachment

General

Created:
Updated:
Size: