Closed Bug 781002 Opened 8 years ago Closed 7 years ago

Story - Apply metro styling to the context menu

Categories

(Tracking Graveyard :: Metro Operations, defect, P2)

All
Windows 8.1
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jimm, Assigned: jwilde)

References

Details

(Whiteboard: feature=story u=metro_firefox_user c=context_menus p=2)

Attachments

(7 files, 1 obsolete file)

The context menu will need metro styling. Currently it has the xul fennec style.
Implementation:
- We need to make sure that there's data pushed from content to chrome about the location that the context menu needs to be shown at.
- Context menus (along with menulists, for that matter) need to be tied to that popup location.
- There needs to be some CSS to style the menus like Metro style menus.
Blocks: 771692
(In reply to Jonathan Wilde [:jwilde] from comment #1)

> - There needs to be some CSS to style the menus like Metro style menus.

Is there a way to pick up the style from the system?
(In reply to Stephen Horlander from comment #2)
> (In reply to Jonathan Wilde [:jwilde] from comment #1)
> 
> > - There needs to be some CSS to style the menus like Metro style menus.
> 
> Is there a way to pick up the style from the system?

Hover and selection color seem to be defined on a per app basis, so I think we can customize those if we want. The basic style though is pretty constant. I've just revamped this a bit in my selection work, I'll post some examples / screen shots here so you can tweak look and feel.
Attached image calendar app hover
these are hard to get. the popups hide when you hit the screen cap buttons. you might want to get a hold of a win8 tablet to take a look at some more.
Attached image current firefox theme
(In reply to Jim Mathies [:jimm] from comment #5)
> Created attachment 651486 [details]
> current firefox theme

(active on the left, hover on the right)
So it looks like certain colors are locked:

1) hover color, which is a gray/brownish
2) active color, which is black

selection color varies between apps.

I'll see if I can track down a system color source for some of these.
Blocks: 785763
Component: Theme → General
Product: Firefox → Firefox for Metro
Component: General → Theme
Keywords: polish
Whiteboard: [metro-mvp][LOE:1]
Priority: -- → P2
Summary: Apply metro styling to the context menu → Story - Apply metro styling to the context menu
Whiteboard: [metro-mvp][LOE:1] → [metro-mvp][LOE:1] feature=story u=metro_firefox_user c=context_menus
Keywords: polish
Whiteboard: [metro-mvp][LOE:1] feature=story u=metro_firefox_user c=context_menus → feature=story u=metro_firefox_user c=context_menus p=0
Whiteboard: feature=story u=metro_firefox_user c=context_menus p=0 → feature=story u=metro_firefox_user c=context_menus p=2
No longer blocks: 785763
This just requires a final sign off on css color codes I think, and any tweaks to layout ux wants.
Keywords: uiwanted
Depends on: 844370
Component: Theme → Metro Operations
Product: Firefox for Metro → Tracking
Version: Trunk → ---
Assignee: nobody → sfoster
Blocks: metrov1it7
No longer blocks: metrov1backlog
Status: NEW → ASSIGNED
QA Contact: jbecerra
I can only find http://msdn.microsoft.com/en-us/library/windows/apps/hh465308.aspx in reference to context menus, which includes nothing about :hover / :active styles. 

From looking around at other apps, it looks like that :active background is a light grey: rgb(222,222,222). However we use the orange everywhere else for a selected color so I'm not sure we should break our own convention here?

I can adjust the padding a little and double-check the popup placement - the MS guidelines indicate it should always be centered on the selection/context and what looks like a few pixels above/below.
Here's the current orange selected color side by side with grey color. 
Padding is adjusted here to roughly align with other apps. Apart from tweaks there, the only other thing I see is that MS' menu text seems to be semi-bold, or perhaps just a larger font-size?
Flags: needinfo?(ywang)
I've always wondered if we should have that gap on the top and bottom. Seems like the top and bottom menu items should sit flush with the border.
I think the SDK's menus have that gap - about every context menu I've seen looks like the grey one on the right. The gap serves show you that the menu item isn't cropped in any way maybe? I can't muster strong feelings about it - seems like you could argue it either way, and it comes down to consistency (with other store apps) vs. aethetics and our own internal consistency.
Assignee: sfoster → shorlander
Assignee: shorlander → sfoster
Flags: needinfo?(ywang) → needinfo?(shorlander)
Did I post further clarification to another bug? Anyhow, this should be a very minor fix so I just need clarification on what menu item states get which color (with color values if we dont use them elsewhere).
Context Menu Colors:

- Hover: Black (#000) text on grey (#ccc) background
- Pressed: White (#fff) text on black (#000) background


It probably doesn't affect this but I should note that context menus have different styling than dropdown menus:

- Hover: Black (#000) text on light-grey (#f0f0f0) background
- Pressed: Black (#000) text on grey (#d3d3d3) background
- Selected: White (#fff) text on orange (#ff8000) background
Flags: needinfo?(shorlander)
Keywords: uiwanted
Hardware: x86_64 → All
Blocks: metrov1it8
No longer blocks: metrov1it7
No longer blocks: metrov1it8
Depends on: 888521
Assignee: sfoster → jwilde
Attached patch patch v1 (obsolete) — Splinter Review
Changing some colors, and doing a little bit of selector and !important tidying.
Attached patch patch v1.1Splinter Review
Better comment for form selects.
Attachment #775033 - Attachment is obsolete: true
Attachment #775035 - Flags: review?(mbrubeck)
Attachment #775035 - Attachment is patch: true
Attachment #775035 - Attachment mime type: text/x-patch → text/plain
Blocks: metrov1it11
No longer blocks: metrov1backlog
Attachment #775035 - Flags: review?(mbrubeck) → review+
Whiteboard: feature=story u=metro_firefox_user c=context_menus p=2 → [leave open] feature=story u=metro_firefox_user c=context_menus p=2
I put a leave open on here, thinking that there might be other work to do, but it looks like we have pretty good coverage of other issues (selection, etc.) in other bugs. Resolving this as fixed.
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Whiteboard: [leave open] feature=story u=metro_firefox_user c=context_menus p=2 → feature=story u=metro_firefox_user c=context_menus p=2
Depends on: 898833
User Agent: Mozilla/5.0 (Windows NT 6.2; Win64; x64; rv:26.0) Gecko/20100101 Firefox/26.0
Build ID: 20130807030216
Built from http://hg.mozilla.org/mozilla-central/rev/1fb5d14e8348

Tested on windows 8 using latest nightly  for iteration-11. I can see context menu as attached here.

Is this desired behavior?
Flags: needinfo?(jmathies)
Looks right to me.
Flags: needinfo?(jmathies)
No longer depends on: 888521
OS: Windows 8 Metro → Windows 8.1
Product: Tracking → Tracking Graveyard
You need to log in before you can comment on or make changes to this bug.