Jared Wein [:jaws] (please needinfo? me) Reporter
	Description • 10 years ago

Bug 1000513 landed but uses the toolbar icons in the mean-time. We need proper 18px by 18px icons (and their HiDPI cousins of 36px by 36px). Also inverted too.

A sprite sheet for these should suffice.

	Jared Wein [:jaws] (please needinfo? me) Reporter
	Comment 1 • 10 years ago

Michael, can you provide these icons?

	Dão Gottwald [:dao] Assignee
	Comment 2 • 10 years ago

Inverted icons will add extra code complexity for deciding when to use them.

Seems like SVG using menuText or -moz-dialogText (I don't remember what color you used in background) would be a good fit here.

	Jared Wein [:jaws] (please needinfo? me) Reporter
	Comment 3 • 10 years ago

(In reply to Dão Gottwald [:dao] from comment #2)
> Seems like SVG using menuText or  (I don't remember what
> color you used in background) would be a good fit here.

We used '-moz-dialog', so '-moz-dialogText'.

	Mayank Bansal
	Comment 4 • 10 years ago

As a Win7 user, If i hover my mouse over a button, and it gets the "3d/raised" effect, then it implies that the button is clickable.  Having this "3d/raised" effect for a disabled button is IMHO very confusing.
Additionally, having a clickable button that does nothing is coinfusing. When a button is supposed to be disabled, dont make it clickable.

As a long time Win7 user, i would expect that when a button is disabled, dont give it the "3d/raised" effect at all.

	Jared Wein [:jaws] (please needinfo? me) Reporter
	Comment 5 • 10 years ago

(In reply to mayankleoboy1 from comment #4)
> As a Win7 user, If i hover my mouse over a button, and it gets the
> "3d/raised" effect, then it implies that the button is clickable.  Having
> this "3d/raised" effect for a disabled button is IMHO very confusing.
> Additionally, having a clickable button that does nothing is coinfusing.
> When a button is supposed to be disabled, dont make it clickable.
> 
> As a long time Win7 user, i would expect that when a button is disabled,
> dont give it the "3d/raised" effect at all.

I'm not sure what this complaint is about? The hover state of context menu items hasn't changed at all with bug 1000513.

	Mayank Bansal
	Comment 6 • 10 years ago

the icons make this prominent, in a way that text did not

	Tim Nguyen :ntim
	Comment 8 • 10 years ago

Why can't we just use the Toolbar.png sprite ? We already have inverted and hdpi for those.
You can check the patch in bug 1016109 for an example.

	Tim Nguyen :ntim
	Comment 9 • 10 years ago

This is a great temporary approach while we wait for icons.

	Michael Maslaney [:mmaslaney] (mmaslaney@mozilla.com)
	Comment 10 • 10 years ago

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #1)
> Michael, can you provide these icons?

Sure thing.

	Tim Nguyen :ntim
	Comment 12 • 10 years ago

Removed a small leftover.

	Dão Gottwald [:dao] Assignee
	Comment 13 • 10 years ago

Comment on attachment 8429564 [details] [diff] [review]
Proposed patch (v1.1) : Make full use of Toolbar-*.png files

We should use proper icons rather than expanding the temporary hack.

	Tim Nguyen :ntim
	Comment 16 • 10 years ago

P1 as we can't ship the menu with bug 1017087 .

	Jared Wein [:jaws] (please needinfo? me) Reporter
	Comment 20 • 10 years ago

(In reply to mmaslaney from comment #10)
> (In reply to Jared Wein [:jaws] (please needinfo? me) from comment #1)
> > Michael, can you provide these icons?
> 
> Sure thing.

Any update on this?

	Michael Maslaney [:mmaslaney] (mmaslaney@mozilla.com)
	Comment 22 • 10 years ago

Stephen and I talked about glyph production today and while both of us agree SVG is the way to go, there needs to be some coordinate with Engineering to define the SVG production process.

In the meantime, use the toolbar.png for all glyphs.

	u428464
	Comment 23 • 10 years ago

In fact AFAIK even those are needed in good quality.

	Dão Gottwald [:dao] Assignee
	Comment 24 • 10 years ago

(In reply to mmaslaney from comment #22)
> Stephen and I talked about glyph production today and while both of us agree
> SVG is the way to go, there needs to be some coordinate with Engineering to
> define the SVG production process.

I don't understand. From an engineering POV it doesn't matter whether we drop in a PNG or an SVG file. What needs to be coordinated here? Are you saying an engineer would need to be involved in creating the file?

	Dão Gottwald [:dao] Assignee
	Comment 25 • 10 years ago

mmaslaney, can you please clarify what needs to be coordinated here? Thanks.

	Blair McBride [:Unfocused] (UNAVAILABLE)
	Comment 26 • 10 years ago

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #0)
> Bug 1000513 landed but uses the toolbar icons in the mean-time. We need
> proper 18px by 18px icons (and their HiDPI cousins of 36px by 36px). Also
> inverted too.

And something suitable for High Contrast mode too (black-on-white and white-on-black). Although we may need bug 1022531 to actually use them.

	Michael Maslaney [:mmaslaney] (mmaslaney@mozilla.com)
	Comment 27 • 10 years ago

Dao, when I speak of coordination, I mean the process of how we produce glyphs as a whole, which is a project in itself. Stephen has outlined the initial plan here:http://cl.ly/image/1x1z1i1f323I

Until then, let's use the toolbar.png file for the contextual icons. Ideally I would like them to have more contrast than the toolbar.png file provides, but I would rather hold off until the new process is setup than give you throw away assets.

If you insist on using SVGs now, I would be happy to provide them, but we may have an updated style in the near future, based on our Stephen's glyph production plan.

	Tim Nguyen :ntim
	Comment 28 • 10 years ago

I think we should land something, at least for Aurora. I don't think we want to ship with blurry icons.

	Justin Dolske [:Dolske]
	Comment 29 • 10 years ago

We should not block this bug on setting up a new process for assets. As Tim noted, this code is already in Aurora, and process changes tend to take a long time.

Let's either land HiDPI+Inverted versions of these icons, or back out until we're ready to ship this. (Doing that with PNG would be the minimal change, but I'd have no objection to doing it "properly" SVG.)

SVG would be required to match the foreground and background color of native context menus on Windows/Linux (which I think is what comment 2 is requesting). But since this this part of the context menu feels different/special now, maybe hardcoding a background color is fine. Or do what we do in the toolbar. (OS X would still need inverted icons for the white-on-blue hover effect.)

	Justin Dolske [:Dolske]
	Comment 30 • 10 years ago

(To be clearer: there's no rush to back out, but I think it would be good to do so not much later than the beginning of beta, if an imminent solution is not in sight.)

	Jared Wein [:jaws] (please needinfo? me) Reporter
	Comment 31 • 10 years ago

Comment on attachment 8429564 [details] [diff] [review]
Proposed patch (v1.1) : Make full use of Toolbar-*.png files

Review of attachment 8429564 [details] [diff] [review]:
-----------------------------------------------------------------

r=me with those changes made.

::: browser/themes/osx/browser.css
@@ +4438,5 @@
>    padding-right: 0;
>  }
> +
> +#context-navigation > :-moz-any(@iconicmenuitems@):hover:not([disabled=true]) > .menuitem-iconic,
> +#context-navigation > :-moz-any(@iconicmenuitems@)[selected="true"] > .menuitem-iconic {

These should be .menu-iconic-left, not .menuitem-iconic.

@@ +4448,5 @@
> +    list-style-image: url("chrome://browser/skin/Toolbar@2x.png");
> +  }
> +
> +  #context-navigation > :-moz-any(@iconicmenuitems@):hover:not([disabled=true]) > .menuitem-iconic,
> +  #context-navigation > :-moz-any(@iconicmenuitems@)[selected="true"] > .menuitem-iconic {

Ditto.

	Dão Gottwald [:dao] Assignee
	Comment 32 • 10 years ago

Comment on attachment 8429564 [details] [diff] [review]
Proposed patch (v1.1) : Make full use of Toolbar-*.png files

It looks like this contains no solution for having the icons visible on dark backgrounds (notably for high-contrast).

(In reply to mmaslaney from comment #27)
> If you insist on using SVGs now, I would be happy to provide them, but we
> may have an updated style in the near future, based on our Stephen's glyph
> production plan.

This doesn't sound like a big deal.

	Dão Gottwald [:dao] Assignee
	Comment 34 • 10 years ago

Comment on attachment 8444511 [details] [diff] [review]
Patch v2 (r=jaws)

still doesn't meet the requirements

	Tim Nguyen :ntim
	Comment 35 • 10 years ago

(In reply to Dão Gottwald [:dao] from comment #32)
> Comment on attachment 8429564 [details] [diff] [review]
> Proposed patch (v1.1) : Make full use of Toolbar-*.png files
> 
> It looks like this contains no solution for having the icons visible on dark
> backgrounds (notably for high-contrast).

What would be your solution for Aurora ? We don't have the SVG, we also don't have a media query targeting high contrast theme.
Nightly can wait for a better solution, but Aurora needs treatment before we can ship the context menu. This patch seems good enough for this purpose.

	Dão Gottwald [:dao] Assignee
	Comment 36 • 10 years ago

(In reply to Tim Nguyen [:ntim] from comment #35)
> What would be your solution for Aurora ? We don't have the SVG,

I'm not sure what you mean. The SVG needs to be created and then it can land on aurora just like on mozilla-central.

> we also don't have a media query targeting high contrast theme.

A media query isn't the ideal solution to that. For instance, it ignores dark Gtk themes. We could pick the icons based on the text color, like we do for toolbars (bug 1012629).

	Jared Wein [:jaws] (please needinfo? me) Reporter
	Comment 37 • 10 years ago

Michael, can you attach the SVG icons?

	Benjamin Smedberg
	Comment 38 • 10 years ago

Does this bug cover that the current "refresh" icon looks like it's disabled (it's the same grey as the disabled forward button) even though it's not disabled?

	Jared Wein [:jaws] (please needinfo? me) Reporter
	Comment 39 • 10 years ago

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #38)
> Does this bug cover that the current "refresh" icon looks like it's disabled
> (it's the same grey as the disabled forward button) even though it's not
> disabled?

Yeah, this bug will fix that.

	Michael Maslaney [:mmaslaney] (mmaslaney@mozilla.com)
	Comment 40 • 10 years ago

Let me know if there are glyphs missing from the attached set.

	Jared Wein [:jaws] (please needinfo? me) Reporter
	Comment 41 • 10 years ago

Yeah, we still need the 'stop' glyph.

	Tim Nguyen :ntim
	Comment 43 • 10 years ago

I didn't know what to do to fix the inverted hover part on Mac (whether I need to use highlightText, or currentColor (not sure if currentColor even works in SVG))

	Tim Nguyen :ntim
	Comment 44 • 10 years ago

Those icons look a bit too dark and bold in my opinion. (I had to change the color since we need to support high contrast themes).

	Dão Gottwald [:dao] Assignee
	Comment 45 • 10 years ago

(In reply to Tim Nguyen [:ntim] from comment #43)
> Created attachment 8450002 [details] [diff] [review]
> SVG Patch v1
> 
> I didn't know what to do to fix the inverted hover part on Mac (whether I
> need to use highlightText, or currentColor (not sure if currentColor even
> works in SVG))

You should use the same color as used by menu.css. For OS X it looks like this is -moz-mac-menutextselect, for Linux and Windows this will be a different value.

	Michael Maslaney [:mmaslaney] (mmaslaney@mozilla.com)
	Comment 46 • 10 years ago

Comment on attachment 8450006 [details]
Screenshot of patch

Refer to comment 45.

	Tim Nguyen :ntim
	Comment 47 • 10 years ago

I won't be able to restart working on this in time for the next merge. I should be back by the end of july, so if you want to take this, feel free too.

	Jared Wein [:jaws] (please needinfo? me) Reporter
	Comment 48 • 10 years ago

Updated the patch with the correct text colors and hover colors.

	Jared Wein [:jaws] (please needinfo? me) Reporter
	Comment 49 • 10 years ago

Comment on attachment 8452330 [details] [diff] [review]
Patch

Michael, you can see this for ui-review, http://screencast.com/t/jyxyEqXC06

Note that I made the icons 16x16 as was requested over IRC:
<mmaslaney> jaws it does feel a bit heavy. Are they sized at 16x16 pixels?
<jaws> they're sized at 18x18
<mmaslaney> jaws I would make them 16x16

	Marco Mucci [:MarcoM]
	Comment 50 • 10 years ago

Hi Jared, can you provide a point value and if the bug should be marked as [qa+] or [qa-]

	Dão Gottwald [:dao] Assignee
	Comment 51 • 10 years ago

Comment on attachment 8452330 [details] [diff] [review]
Patch

>+<?xml version="1.0" encoding="utf-8"?>

remove encoding="utf-8"

>+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">

remove this line and add a license header

>+<svg version="1.1" id="Icons" 
>+  xmlns="http://www.w3.org/2000/svg" 
>+  xmlns:xlink="http://www.w3.org/1999/xlink" 
>+  x="0px" y="0px" 
>+  viewBox="0 0 16 16" 
>+  enable-background="new 0 0 16 16" 

trailing spaces

I believe the version, id and xmlns:xlink attributes can go too.

>+path {
>+#if XP_MACOSX
>+  fill: -moz-fieldtext;
>+#else
>+  fill: menutext;
>+#endif

Why are you using -moz-fieldtext instead of menutext on OS X?

>+g.active > path {
>+#if XP_MACOSX
>+  fill: -moz-mac-menutextselect;
>+#else
>+  fill: -moz-menuhovertext;
>+#endif
>+}

I think you should move this file out of shared/. The preprocessing breaks viewing and editing the image from the uncompiled source.

	Marco Mucci [:MarcoM]
	Comment 52 • 10 years ago

Removed from iteration 33.3

	Dão Gottwald [:dao] Assignee
	Comment 53 • 10 years ago

taking over since Jaws is away

	Tim Nguyen :ntim
	Comment 54 • 10 years ago

Comment on attachment 8456924 [details] [diff] [review]
patch

Review of attachment 8456924 [details] [diff] [review]:
-----------------------------------------------------------------

According to Comment 3, we used -moz-dialog as background, so we should use -moz-dialogText for the normal state.
Btw, in content-contextmenu.svg at line 14, there seems to be a missing line break (can't seem to use the comment feature properly from my tablet)

	Mike de Boer [:mikedeboer]
	Comment 56 • 10 years ago

Comment on attachment 8457073 [details] [diff] [review]
patch v2

Review of attachment 8457073 [details] [diff] [review]:
-----------------------------------------------------------------

I'm afraid this patch doesn't show any icons for me in the context menu on OSX or Linux. At this point I suspect they won't show on Windows either.

<3 that we're using SVG here! I wholly support a 'stealthy', pragmatic upgrade path toward SVG-all-the-things.

I found a few nits, they apply for all three SVG files.

::: browser/themes/linux/content-contextmenu.svg
@@ +7,5 @@
> +     viewBox="0 0 16 16"
> +     enable-background="new 0 0 16 16"
> +     xml:space="preserve">
> +<style>
> +

nit: unnecessary newline.

@@ +19,5 @@
> +
> +g.active > path {
> +  fill: -moz-menuhovertext;
> +}
> +

nit: same.

@@ +39,5 @@
> +<g id="reload">
> +  <path fill-rule="evenodd" clip-rule="evenodd" d="M15.429,8h-8l3.207-3.207C9.889,4.265,8.986,3.947,8,3.947
> +  c-2.554,0-4.625,2.071-4.625,4.625S5.446,13.196,8,13.196c1.638,0,3.069-0.857,3.891-2.141l2.576,1.104
> +  C13.199,14.439,10.794,16,8,16c-4.103,0-7.429-3.326-7.429-7.429S3.897,1.143,8,1.143c1.762,0,3.366,0.624,4.631,1.654L15.429,0V8z"
> +  />

nit: in some places the closing 'tag' ended up on its own line. Can you place it at the end of the path? Also, the indentation of the path looks different for these paths.

@@ +42,5 @@
> +  C13.199,14.439,10.794,16,8,16c-4.103,0-7.429-3.326-7.429-7.429S3.897,1.143,8,1.143c1.762,0,3.366,0.624,4.631,1.654L15.429,0V8z"
> +  />
> +</g>
> +<g id="stop">
> +  <polygon fill-rule="evenodd" clip-rule="evenodd" points="16,2.748 13.338,0.079 8.038,5.391 2.661,0 0,2.669 

*gasp* A    TRAILING      WHITESPACE     !

@@ +81,5 @@
> +  C13.199,14.439,10.794,16,8,16c-4.103,0-7.429-3.326-7.429-7.429S3.897,1.143,8,1.143c1.762,0,3.366,0.624,4.631,1.654L15.429,0V8z"
> +  />
> +</g>
> +<g id="stop-active" class="active">
> +  <polygon fill-rule="evenodd" clip-rule="evenodd" points="16,2.748 13.338,0.079 8.038,5.391 2.661,0 0,2.669 

nit: same ;)

	Dão Gottwald [:dao] Assignee
	Comment 57 • 10 years ago

> I'm afraid this patch doesn't show any icons for me in the context menu on
> OSX or Linux. At this point I suspect they won't show on Windows either.

Ugh, that's some weird combination of a build issue (probably only affects local builds) and possibly a Gecko bug. If I add * in jar.mn such that the svg is copied rather than linked (even though there's nothing to preprocess), the issue disappears...

	Mike de Boer [:mikedeboer]
	Comment 59 • 10 years ago

Comment on attachment 8457896 [details] [diff] [review]
patch v3

Review of attachment 8457896 [details] [diff] [review]:
-----------------------------------------------------------------

Epic stuff! Looks gorgious on Mac Retina, Windows & Linux.

Well done :)

(my 3 nits apply to all three SVG files)

::: browser/themes/linux/content-contextmenu.svg
@@ +40,5 @@
> +    C13.199,14.439,10.794,16,8,16c-4.103,0-7.429-3.326-7.429-7.429S3.897,1.143,8,1.143c1.762,0,3.366,0.624,4.631,1.654L15.429,0V8z"/>
> +</g>
> +<g id="stop">
> +  <polygon fill-rule="evenodd" clip-rule="evenodd" points="16,2.748 13.338,0.079 8.038,5.391 2.661,0 0,2.669
> +    5.377,8.059 0.157,13.292 2.819,15.961 8.039,10.728 13.298,16 15.959,13.331 10.701,8.06  "/>

nit: spaces not need at the end of this set of points.

@@ +78,5 @@
> +    C13.199,14.439,10.794,16,8,16c-4.103,0-7.429-3.326-7.429-7.429S3.897,1.143,8,1.143c1.762,0,3.366,0.624,4.631,1.654L15.429,0V8z"/>
> +</g>
> +<g id="stop-active" class="active">
> +  <polygon fill-rule="evenodd" clip-rule="evenodd" points="16,2.748 13.338,0.079 8.038,5.391 2.661,0 0,2.669
> +    5.377,8.059 0.157,13.292 2.819,15.961 8.039,10.728 13.298,16 15.959,13.331 10.701,8.06  "/>

nit: same here.

@@ +94,5 @@
> +    l3.124,3.262l-0.692,4.589C2.679,15.596,2.957,16,3.444,16c0.185,0,0.401-0.058,0.637-0.181L8,13.744l3.919,2.075
> +    C12.156,15.942,12.372,16,12.557,16c0.487,0,0.764-0.404,0.661-1.094l-0.69-4.589l3.12-3.259c0.668-0.703,0.43-1.406-0.532-1.566
> +    l-4.317-0.72L8.775,0.651C8.562,0.217,8.281,0,8,0L8,0z"/>
> +</g>
> +

nit: empty line not necessary here.

	Mike de Boer [:mikedeboer]
	Comment 60 • 10 years ago

*gorgeous

	Dão Gottwald [:dao] Assignee
	Comment 61 • 10 years ago

remaining nits addressed

https://hg.mozilla.org/integration/fx-team/rev/f66e8d909983

	Ryan VanderMeulen [:RyanVM]
	Comment 62 • 10 years ago

https://hg.mozilla.org/mozilla-central/rev/f66e8d909983

	Marco Mucci [:MarcoM]
	Comment 63 • 10 years ago

Hi Florin, can a QA contact be assigned for verification of this bug.

	Simonas Kazlauskas [:nagisa/:simukis]
	Comment 64 • 10 years ago

Bug 1018595 is not quite fixed by this (see bug 1018595 comment 3). While buttons do not have any margin on sides anymore (yay), they still have margin on top (nay).

	Simonas Kazlauskas [:nagisa/:simukis]
	Comment 65 • 10 years ago

Stop button icon colour is not inverted. All other buttons, including the refresh button, appear to inverted when highlighted.

(note: screenshot done after a patch to remove top padding)

	Tim Nguyen :ntim
	Comment 66 • 10 years ago

(In reply to Simonas Kazlauskas [:simukis] from comment #65)
> Created attachment 8458693 [details]
> Screenshot from 2014-07-18 17:28:08.png
> 
> Stop button icon colour is not inverted. All other buttons, including the
> refresh button, appear to inverted when highlighted.
> 
> (note: screenshot done after a patch to remove top padding)
This is because stop uses a polygon and not a path so CSS rules don't apply. Please file a new bug.

	Cornel Ionce [:noni] [Hubs QA]
	Comment 68 • 10 years ago

Verified on latest Nightly, build ID: 20140720030203.

I've noticed two things for the Context Menu while using High Contrast Themes on Windows 7 64bit:
1. Using High Contrast Black, the Stop (X) button is not visible (visible if hovered).
2. Using High Contrast White, the inactive icons are not visible when hovered.

Any thoughts?

	Tim Nguyen :ntim
	Comment 69 • 10 years ago

Issue 1) is Bug 1041121

	Cornel Ionce [:noni] [Hubs QA]
	Comment 70 • 10 years ago

Thanks Tim, 

I've logged bug 1041969 for the other issue and commented in bug 1041121.

	Dão Gottwald [:dao] Assignee
	Comment 71 • 10 years ago

Comment on attachment 8457960 [details] [diff] [review]
patch v4

Approval Request Comment
[Feature/regressing bug #]: bug 1000513
[User impact if declined]: context menu using placeholder images with various aesthetic and usability flaws
[Describe test coverage new/current, TBPL]: only theme code with no test coverage
[Risks and why]: low, but we'll need to fix and uplift bug 1041121 and bug 1041969 too
[String/UUID change made/needed]: none

	Florian Quèze [:florian]
	Comment 72 • 10 years ago

(In reply to Dão Gottwald [:dao] from comment #57)
> > I'm afraid this patch doesn't show any icons for me in the context menu on
> > OSX or Linux. At this point I suspect they won't show on Windows either.
> 
> Ugh, that's some weird combination of a build issue (probably only affects
> local builds) and possibly a Gecko bug. If I add * in jar.mn such that the
> svg is copied rather than linked (even though there's nothing to
> preprocess), the issue disappears...

So what was the problem here exactly? Would using '+' instead of '*' give you the same result and spare us the "browser/themes/osx/content-contextmenu.svg: WARNING: no preprocessor directives found" warning?

	Lawrence Mandel [:lmandel] (use needinfo)
	Comment 73 • 10 years ago

(In reply to Dão Gottwald [:dao] from comment #71)
> [Risks and why]: low, but we'll need to fix and uplift bug 1041121 and bug
> 1041969 too

Bug 1041969 is assigned to the current desktop sprint. Bug 1041121 looks unowned. I have flagged both for tracking. Do you need all of these bugs to land at the same time?

	Dão Gottwald [:dao] Assignee
	Comment 74 • 10 years ago

(In reply to Lawrence Mandel [:lmandel] from comment #73)
> (In reply to Dão Gottwald [:dao] from comment #71)
> > [Risks and why]: low, but we'll need to fix and uplift bug 1041121 and bug
> > 1041969 too
> 
> Bug 1041969 is assigned to the current desktop sprint. Bug 1041121 looks
> unowned. I have flagged both for tracking. Do you need all of these bugs to
> land at the same time?

They can land separately.

	Lawrence Mandel [:lmandel] (use needinfo)
	Comment 75 • 10 years ago

Comment on attachment 8457960 [details] [diff] [review]
patch v4

beta+

	Cornel Ionce [:noni] [Hubs QA]
	Comment 76 • 10 years ago

If bug 1041969 and bug 1041121 will land separately, I consider it's safe to mark this issue verified on the 33 branch.
Tested on Latest Nightly 34 (build ID: 20140727030204) and Latest Aurora 33 (build ID: 20140727004002).

Will leave the bug status unchanged until beta verification.

	Ryan VanderMeulen [:RyanVM]
	Comment 77 • 10 years ago

Needs rebasing for beta uplift.

	Dão Gottwald [:dao] Assignee
	Comment 78 • 10 years ago

https://hg.mozilla.org/releases/mozilla-beta/rev/92bb440bf6d6

	Camelia Badau [:cbadau], Desktop QA
	Comment 79 • 10 years ago

Verified on Firefox 32 Beta 3 and it works as expected, except for the following problem: the hovered active buttons remain highlighted while using High Contrast White Theme, which is mentioned in bug 993387 comment #5.