Closed Bug 1016405 Opened 6 years ago Closed 5 years ago

Update the icons in the context menu to have the correct size, HiDPI, and inverted variants

Categories

(Firefox :: Theme, defect, P1)

defect
Points:
2

Tracking

()

VERIFIED FIXED
Firefox 33
Iteration:
34.1
Tracking Status
firefox30 --- unaffected
firefox31 --- unaffected
firefox32 + verified
firefox33 --- verified

People

(Reporter: jaws, Assigned: dao)

References

(Blocks 2 open bugs)

Details

Attachments

(3 files, 10 obsolete files)

36.33 KB, application/zip
Details
27.76 KB, patch
Details | Diff | Splinter Review
16.04 KB, image/png
Details
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.
Michael, can you provide these icons?
Flags: needinfo?(mmaslaney)
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.
Component: Menus → Theme
(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'.
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.
(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.
the icons make this prominent, in a way that text did not
Duplicate of this bug: 1016109
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.
This is a great temporary approach while we wait for icons.
Assignee: nobody → ntim007
Status: NEW → ASSIGNED
Attachment #8429445 - Flags: review?(jaws)
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #1)
> Michael, can you provide these icons?

Sure thing.
Flags: needinfo?(mmaslaney)
Removed a small leftover.
Attachment #8429445 - Attachment is obsolete: true
Attachment #8429445 - Flags: review?(jaws)
Attachment #8429564 - Flags: review?(jaws)
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.
Attachment #8429564 - Attachment is obsolete: true
Attachment #8429564 - Flags: review?(jaws)
Assignee: ntim007 → nobody
Status: ASSIGNED → NEW
Duplicate of this bug: 1017087
P1 as we can't ship the menu with bug 1017087 .
Priority: -- → P1
(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?
Flags: needinfo?(mmaslaney)
Duplicate of this bug: 1020955
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.
Flags: needinfo?(mmaslaney)
In fact AFAIK even those are needed in good quality.
(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?
Flags: needinfo?(mmaslaney)
Flags: needinfo?(mmaslaney)
mmaslaney, can you please clarify what needs to be coordinated here? Thanks.
Flags: needinfo?(mmaslaney)
Blocks: 1016548
(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.
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.
Flags: needinfo?(mmaslaney)
Flags: firefox-backlog+
I think we should land something, at least for Aurora. I don't think we want to ship with blurry icons.
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.)
(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.)
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.
Attachment #8429564 - Flags: review?(jaws) → review+
Assignee: nobody → ntim007
Status: NEW → ASSIGNED
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.
Attachment #8429564 - Flags: review-
Attached patch Patch v2 (r=jaws) (obsolete) — Splinter Review
Attachment #8429564 - Attachment is obsolete: true
Attachment #8444511 - Flags: review+
Comment on attachment 8444511 [details] [diff] [review]
Patch v2 (r=jaws)

still doesn't meet the requirements
Attachment #8444511 - Flags: review+ → review-
(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.
Flags: needinfo?(dao)
(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).
Flags: needinfo?(dao)
Michael, can you attach the SVG icons?
Flags: needinfo?(mmaslaney)
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?
Flags: needinfo?(ntim007)
(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.
Flags: needinfo?(ntim007)
Attached file contextual-menu-glyphs.zip (obsolete) —
Let me know if there are glyphs missing from the attached set.
Flags: needinfo?(mmaslaney)
Yeah, we still need the 'stop' glyph.
Flags: needinfo?(mmaslaney)
Attached patch SVG Patch v1 (obsolete) — Splinter Review
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))
Attachment #8444511 - Attachment is obsolete: true
Attachment #8449713 - Attachment is obsolete: true
Attachment #8450002 - Flags: review?(jaws)
Attached image Screenshot of patch (obsolete) —
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).
Attachment #8450006 - Flags: ui-review?(mmaslaney)
(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.
Comment on attachment 8450006 [details]
Screenshot of patch

Refer to comment 45.
Attachment #8450006 - Flags: ui-review?(mmaslaney) → ui-review-
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.
Attached patch Patch (obsolete) — Splinter Review
Updated the patch with the correct text colors and hover colors.
Assignee: ntim007 → jaws
Attachment #8450002 - Attachment is obsolete: true
Attachment #8450006 - Attachment is obsolete: true
Attachment #8452330 - Flags: review?(dao)
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
Hi Jared, can you provide a point value and if the bug should be marked as [qa+] or [qa-]
Iteration: --- → 33.3
Flags: needinfo?(jaws)
Points: --- → 2
QA Whiteboard: [qa+]
Flags: needinfo?(jaws)
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.
Attachment #8452330 - Flags: review?(dao) → review-
Attachment #8452330 - Flags: ui-review?(mmaslaney) → ui-review+
Removed from iteration 33.3
Iteration: 33.3 → ---
Attached patch patch (obsolete) — Splinter Review
taking over since Jaws is away
Assignee: jaws → dao
Attachment #8452330 - Attachment is obsolete: true
Attachment #8456924 - Flags: review?(mdeboer)
Iteration: --- → 33.3
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)
Attached patch patch v2 (obsolete) — Splinter Review
Attachment #8456924 - Attachment is obsolete: true
Attachment #8456924 - Flags: review?(mdeboer)
Attachment #8457073 - Flags: review?(mdeboer)
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 ;)
Attachment #8457073 - Flags: review?(mdeboer)
> 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...
Attached patch patch v3 (obsolete) — Splinter Review
Attachment #8457073 - Attachment is obsolete: true
Attachment #8457896 - Flags: review?(mdeboer)
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.
Attachment #8457896 - Flags: review?(mdeboer) → review+
*gorgeous
Attached patch patch v4Splinter Review
remaining nits addressed

https://hg.mozilla.org/integration/fx-team/rev/f66e8d909983
Attachment #8457896 - Attachment is obsolete: true
https://hg.mozilla.org/mozilla-central/rev/f66e8d909983
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 33
Hi Florin, can a QA contact be assigned for verification of this bug.
Flags: needinfo?(florin.mezei)
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).
Flags: needinfo?(florin.mezei)
QA Contact: cornel.ionce
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)
(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.
Depends on: 1041121
See Also: 1041121
Duplicate of this bug: 1026013
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?
Flags: needinfo?(dao)
Issue 1) is Bug 1041121
Iteration: 33.3 → 34.1
Thanks Tim, 

I've logged bug 1041969 for the other issue and commented in bug 1041121.
Flags: needinfo?(dao)
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
Attachment #8457960 - Flags: approval-mozilla-beta?
(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?
(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?
Flags: needinfo?(dao)
(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.
Flags: needinfo?(dao)
Comment on attachment 8457960 [details] [diff] [review]
patch v4

beta+
Attachment #8457960 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
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.
QA Whiteboard: [qa+] → [qa!]
Needs rebasing for beta uplift.
Flags: needinfo?(dao)
QA Whiteboard: [qa!] → [qa+]
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.
Status: RESOLVED → VERIFIED
QA Whiteboard: [qa+] → [qa!]
Blocks: 1051117
Depends on: 1062239
You need to log in before you can comment on or make changes to this bug.