Closed Bug 975794 Opened 6 years ago Closed 6 years ago

Toolbarbuttons in the menu panel shouldn't get an inverted dropmarker when using a dark LWT

Categories

(Firefox :: Theme, defect)

x86
Windows 7
defect
Not set

Tracking

()

RESOLVED FIXED
Firefox 30
Tracking Status
firefox29 --- fixed
firefox30 --- fixed

People

(Reporter: fx4waldi, Assigned: fx4waldi)

References

(Blocks 1 open bug)

Details

(Whiteboard: [Australis:P3-])

Attachments

(2 files, 1 obsolete file)

Attached image 23-02-2014.PNG
Inverted color of dropmarker on menu-panel if the LWT is dark
Attached patch Patch 1 (obsolete) — Splinter Review
Attachment #8380313 - Flags: review?(gijskruitbosch+bugs)
Blocks: 940307
Comment on attachment 8380313 [details] [diff] [review]
Patch 1

I think it would make more sense to update http://hg.mozilla.org/mozilla-central/annotate/31113754db3b/browser/themes/windows/browser.css#l474 to only affect buttons in a toolbar.
Attachment #8380313 - Flags: review?(gijskruitbosch+bugs) → review-
Attached patch Patch 2Splinter Review
Attachment #8380313 - Attachment is obsolete: true
Attachment #8380583 - Flags: review?(dao)
Comment on attachment 8380583 [details] [diff] [review]
Patch 2

Unfortunate descendent selector, but I see no better choice.
Attachment #8380583 - Flags: review?(dao) → review+
Thanks for fixing this!
Assignee: nobody → fx4waldi
Keywords: checkin-needed
Summary: Inverted color of dropmarker on menu-panel if the LWT is dark → Toolbarbuttons in the menu panel shouldn't get an inverted dropmarker when using a dark LWT
(In reply to Dão Gottwald [:dao] from comment #4)
> Comment on attachment 8380583 [details] [diff] [review]
> Patch 2
> 
> Unfortunate descendent selector, but I see no better choice.

Why not use [cui-areatype="toolbar"]:not(.overflowedItem) ? This is how we've tended to solve this elsewhere...
Thanks for the patch! Can you please update it with commit information and re-request checkin? :)
https://developer.mozilla.org/en-US/docs/Mercurial_FAQ#How_can_I_generate_a_patch_for_somebody_else_to_check-in_for_me.3F
Keywords: checkin-needed
(In reply to :Gijs Kruitbosch from comment #6)
> (In reply to Dão Gottwald [:dao] from comment #4)
> > Comment on attachment 8380583 [details] [diff] [review]
> > Patch 2
> > 
> > Unfortunate descendent selector, but I see no better choice.
> 
> Why not use [cui-areatype="toolbar"]:not(.overflowedItem) ?

Because the cui-areatype isn't set on toolbarbuttons in a toolbaritem, for instance.

> This is how we've tended to solve this elsewhere...

When combined with .toolbarbutton-1, that would be a bug.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Need an updated patch before this can land, per comment 7. Unless someone else wants to fix & land it.
Flags: needinfo?(fx4waldi)
Whiteboard: [Australis:P3-]
Whiteboard: [Australis:P3-] → [Australis:P3-][fixed-in-fx-team]
https://hg.mozilla.org/mozilla-central/rev/4ece8b3d89cd
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Whiteboard: [Australis:P3-][fixed-in-fx-team] → [Australis:P3-]
Target Milestone: --- → Firefox 30
Comment on attachment 8380583 [details] [diff] [review]
Patch 2

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Australis
User impact if declined: toolbarbuttons with dropmarkers (type menu and menu-button) have their dropmarker inverted when using an LWT, making them hard to see.
Testing completed (on m-c, etc.): on m-c for a while
Risk to taking this patch (and alternatives if risky): very low
String or IDL/UUID changes made by this patch: none
Attachment #8380583 - Flags: approval-mozilla-aurora?
Attachment #8380583 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
QA Whiteboard: [qa-]
You need to log in before you can comment on or make changes to this bug.