Closed Bug 669342 Opened 8 years ago Closed 8 years ago

Menulists for inline preferences should use the Add-ons Manager styling

Categories

(Toolkit :: Add-ons Manager, defect)

7 Branch
All
Windows XP
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla8
Tracking Status
firefox7 - ---

People

(Reporter: whimboo, Assigned: Unfocused)

References

Details

(Keywords: uiwanted)

Attachments

(3 files)

Attached image screenshot
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0a1) Gecko/20110630 Firefox/7.0a1

Menulist items for inline preferences don't use the general styling of the add-ons manager. Currently the styling is broken at least on Windows (see screenshot) but also on other platforms this element doesn't match the AOM styling.
Boriss, we need to decide if this is bad enough to either pull the feature or try a small update on the aurora branch
Keywords: uiwanted
Version: 5 Branch → 7 Branch
Attached patch patchSplinter Review
AFACT it's just a Windows classic problem.
Assignee: nobody → geoff
Status: NEW → ASSIGNED
Attachment #544107 - Flags: review?(dtownsend)
Is this feature hooked up to primary UI anywhere? If it's still only accessible via an about: URL and this issue doesn't cause dataloss or some other profile damage, I cannot see the release team tracking this. Please re-nominate if I've misunderstood or got the facts wrong. Thanks.
This has always been visible in primary UI, in the details view of add-ons that have added inline preferences. It is still purely cosmetic so I suspect it isn't a big deal.
I'm sorry. I misunderstood the bug. Release drivers will evaluate at the next triage session. I suspect that they will not be able to add any value by tracking this. I'll bet we'd be pretty happy to approve a css fix that cleans it up though :-)
(In reply to comment #3)
> AFACT it's just a Windows classic problem.

Not only. There is a bit different behavior on other platforms or themes too. At least on Windows 7 when you focus the menulist, we only highlight the selected value instead of using a light blue background over the whole element. Compare it to the menulist in the general preferences. Also on OS X the style of the menulist doesn't look that well.
Comment on attachment 544107 [details] [diff] [review]
patch

This does correct part of the problem but the focus behaviour is still wrong and as Henrik says there is no drop-marker on OSX.
Attachment #544107 - Flags: review?(dtownsend) → review-
By focus do you mean hover? (In which case the AM buttons are also wrong.)

As for OSX, would the same CSS fix that problem? I have no way to test it.
(In reply to comment #9)
> By focus do you mean hover? (In which case the AM buttons are also wrong.)

Bug 646713 handles that (I have a patch, but its dependent on other un-reviewed stuff).

But I think Henrik means when the element has keyboard focus (like when you've tabbed to that element). So, when menulist:focus and menulist:-moz-focusring would apply.

Note that bug 658530 has a patch that moves all the buttons/menulists stylings into inContentUI.css, and fixes up a bunch of things. That got r- in part because it made the menulists look too much like buttons (I need to ask shorlander about that), But if this bug needs a quick fix now, you may be able to borrow some code.
not going to track this but we'd consider a patch if one materializes.
Meant to reload it before saving, but I accidentally changed the value of tracking-firefox7.  Sorry!  I set it back the way it was.
No actually I can't put it back.  Asa or someone else will have to.
Blair I'm sending this to you because I don't have the means to check that what I'm doing works, and also I'm going to be mostly unavailable for the next week and a bit.
Assignee: geoff → bmcbride
Can we get an update here? No further activity happened in the last 7 days.
(In reply to comment #15)
> Can we get an update here? No further activity happened in the last 7 days.

I was under the impression this wasn't a high priority after all, since it's just cosmetic. So I wasn't going to look at it until I get back home (next week) - since I don't have easy access to OSX until then.
It's not a high priority.
(In reply to Blair McBride (:Unfocused) from comment #16)
> I was under the impression this wasn't a high priority after all, since it's
> just cosmetic. So I wasn't going to look at it until I get back home (next
> week) - since I don't have easy access to OSX until then.

On OS X it looks fine. Windows is the only affected platform here.
OS: All → Windows XP
Oops, forgot to mark this fixed.

There was an issue on OSX, as well as non-aero Windows. Both fixed by Part 1 of bug 658530.
http://hg.mozilla.org/mozilla-central/rev/fd84808b1edd
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Flags: in-testsuite-
Flags: in-litmus-
Resolution: --- → FIXED
Verified fixed with builds on all platforms like Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0a2) Gecko/20110824 Firefox/8.0a2
Status: RESOLVED → VERIFIED
Target Milestone: --- → mozilla8
You need to log in before you can comment on or make changes to this bug.