It seems we have never had any glyph for the '-moz-context-menu' (now also known as 'context-menu') cursor on Windows. This is a followup from bug 163174, with testcase: http://bugzilla.mozilla.org/attachment.cgi?id=154812&action=view

As an example, see kThemeContextualMenuArrowCursor at the following URL. http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGCursors/chapter_6_section_2.html

Don't forget to update the following files (for static builds): browser/app/splash.rc calendar/sunbird/app/splash.rc xulrunner/app/splash.rc (see bug 260713)

I created a custom-made contex-menu win32 .cur http://www.gtalbot.org/GRAPHICS/ICO/Custom_made_context-menu.cur which can be viewed with MSIE 6 at http://www.gtalbot.org/HTMLJavascriptCSS/Cursors.html#CSS3 Size, position, colors, outlines, shape of the context-menu in the cursor file are always modifiable.

To do: - convert the .cur from 256 colors to 16 colors to reduce size (currently 2998 bytes with 256 colors). Look change (gray colors) is barely noticeable - test new .cur in various background colors; had white outline if needed. I could easily create one with only white and black colors... as soon as/if we all agree on the shape of the context-menu glyph and its position in the cursor file.

Custom-made context-menu win32 .cur http://www.gtalbot.org/GRAPHICS/ICO/Custom_made_context-menu2.cur 2 colors, 326 bytes which can be viewed with MSIE 6 (there is a .gif image of the cursor) at http://www.gtalbot.org/HTMLJavascriptCSS/Cursors.html#CSS3 and tested with MSIE 6 on white and black background at http://www.gtalbot.org/HTMLJavascriptCSS/Cursors.html#TestingDivContextMenu That context-menu cursor's hot spot is located at the top tip of the arrow.

Comment on attachment 169071 [details] custom context-menu cursor (.CUR) for CSS3 Is that arrow deliberately larger than a standard Windows arrow cursor?

This arrow is actually equal in size to the standard Windows arrow cursor, at least for WinXP. However, windows cursors for 'progress' and 'help' have smaller arrows.

Another variant for this CSS cursor: -> larger context menu glyph -> less abstract menu items inside that context menu glyph -> increased space between the arrow and the context menu glyph: now the arrow's shadow (by default, cursors cast shadows on background in Windows XP and, IIRC, in Win2000 and/or WinME) touches the adjacent context menu glyph only slightly, so overall legibility of the cursor is somewhat better, IMHO P. S. According to corrections made by neil.parkwaycc.co.uk@myrealbox.com, MIME type set to image/x-icon, so this attachment to the bug must be directly visible in Mozilla and in Firefox. Use right click to save.

Adding Michael Kaply (IBM) to CC list of this bug -- according to his own recommendation left in the bug 258966 comment 1.

> -> larger context menu glyph Sergey, I think yours is big. Mac context-menu cursor uses a rather small context-menu glyph. > -> less abstract menu items inside that context menu glyph I'm not sure I understand what you mean. > -> increased space between the arrow and the context menu glyph: now the > arrow's shadow (by default, cursors cast shadows on background in Windows XP Pointer shadows are by default? In any case, I don't see pointer shadow on the moz ones: alias, copy, cell cursors.

In native Windows applications, the cursor for areas with a shortcut menu has always been identical to the normal cursor. Using a custom cursor will achieve little apart from annoying people with a non-default normal cursor.

i'd rather wontfix this. i agree with mpt.

It seems that you just don't understand what this bug is about. The context-menu cursor glyph in not intended to be used inside the context menu itself; it's rather used to indicate the presence of it (a context menu) for a certain item of the webpage, i.e. the ability of right mouse click that will bring such a menu on screen. And it is usually shown when the mouse hovers over the link. So I strongly oppose wontfixing of this bug.

to be clear, i understand what this bug is for. and now i'm wontfixing it. note that i am a peer and it is well within my right to wontfix this bug. thank you for your efforts, if you're interested in continuing to contribute to mozilla (especially) windows, i'll gladly offer you other bugs on which you could work.

I am not questioning your rights, I just don't like the decision not to implement this glyph, so CSS3 support in this area seems not to be completed. If you're gladly offering us other bugs on which we could work, go on, drop some "bug XXXXXX" keystrokes here.

(In reply to comment #11) > In native Windows applications, the cursor for areas with a shortcut menu > has always been identical to the normal cursor. Using a custom cursor will > achieve little apart from annoying people with a non-default normal cursor. The intention of this bug was merely to add a glyph for 'cursor:context-menu', NOT to change Mozilla/Firefox UA stylesheets so that they would actually use that value for areas where a context menu is available (which indeed would be annoying). The spec is a bit unclear on what the desirable rendering is: http://www.w3.org/TR/css3-ui/#cursor "The UA may treat unsupported values as 'auto'. E.g. on platforms that do not have a concept of a 'context-menu' cursor, the UA may render 'default' or whatever is appropriate." So, we MAY render the 'default' glyph on Windows, but is that also the desired rendering if one has a choice? I think it is, and the spec needs to be clarified. If so, we should remove the 'context-menu' glyphs on some platforms... (e.g. gtk/gtk2)

If we don't implement this, we won't be CSS3 compliant, will we?

We will if it's the correct context-menu cursor for the platform.

I'm saddened by the decision to wontfix this bug which I think was hasty, insufficiently justified IMO. There are cases where a context-menu cursor would make sense like an img with a longdesc attribute (see bug 1996 comment #29 and #30). Also http://www.w3.org/TR/UAAG10-TECHS/guidelines.html#long-descriptions I would have been against implementing a context-menu cursor and to change the arrow cursor for every single cases where an element has indeed a context-menu: pretty much all elements in a page has a context-menu popping when doing a right-click. Maybe this is what timeless understood. 2 comments in this bug are about when and where to use, implement context-menu cursor... but strictly speaking, that was not what this bug was about. There are other bugs filed to implement custom cursors for defined, precise cases: bug 246481, bug 169678 for starters. Are these 2 bugs going to be wontfix as well because the cursor for links in Windows has always been an arrow? I've filed bug 230337 and bug 230081 and even done the art work: have I totally lost my time? Please someone answer me. I'm more in a mood of trying to understand what's happened and what will happen next in other custom cursor bugs here than anything else.

(In reply to comment #16) > The spec is a bit unclear on what the desirable rendering is: > http://www.w3.org/TR/css3-ui/#cursor > "The UA may treat unsupported values as 'auto'. E.g. on platforms that do not > have a concept of a 'context-menu' cursor, the UA may render 'default' or > whatever is appropriate." I think what the spec meant to say is that if an UA does not support all CSS3 cursors or a particular CSS3 cursor, then the rendered cursor should default as default. E.g. td {cursor: cell;} In case the UA does not have implemented the cell cursor, then it should default to default. This fallback mechanism is what happens for UA not supporting specific Mozilla cursors. MSIE 6 will render img.draggable {cursor: -moz-grab;} as an arrow cursor which is the default for img.

Let me try to summarize most of the arguments for fixing this. If you think that the idea of implementing a different custom cursor for CSS3 context-menu is annoying for those who are accustomed to the fact that cursor for areas with a shortcut menu has always been identical to the normal cursor, then, maybe you'd allow it to be exactly the same by default, but still implemented in C++ in such a way that will allow some of the above glyphs if triggered by some hidden about:config boolean value, or an external Firefox extension? Let the users judge whether it's a feature to have a different custom cursor for CSS3 context-menu! Face it: the Web already breaks some default habits of Windows' users, e.g. doubleclick is almost never used in the Web, though very popular on Windows desktop -- but is anyone annoyed? It's even more questionable whether "the browser will be CSS3 compliant if it's the correct context-menu cursor for the platform". First of all, what is the correct context-menu cursor for Windows? Typically, under Start --> Control Panel --> Mouse, there are only fifteen system cursors; comparing them to http://www.w3.org/TR/css3-ui/#cursor0 specifications, we may identify them as (in order of appearance) default, help, progress, wait, crosshair, text, [custom cursor for handwriting], not-allowed, ns-resize, ew-resize, nwse-resize, nesw-resize, move, n-resize (or, more likely, another custom cursor for special selection), and pointer. So, among thirty CSS3 cursors of http://www.w3.org/TR/css3-ui/#cursor0 specs, we have less than a half system ones. Pity, eh? It's highly questionable whether it can be called standard compliance if we drop cursors that are not directly declared ("correct") by OS -- highly questionable, because this way we may drop a lot of these things. Probably my counting is not quite correct... because I know also that there's a usual practice of cloning resize cursors, and it's adopted by Firefox: ew-resize --> e-resize, w-resize ns-resize --> n-resize, s-resize nesw-resize --> ne-resize, sw-resize nwse-resize --> nw-resize, se-resize But, after that, still and again, what's the fate of other cursors -- context-menu, cell, vertical-text, alias, copy, no-drop, col-resize, row-resize, all-scroll? They are not system: for example, there are such (or similar) cursors in popular applications (MS Office, Windows Explorer, etc.), but those cursors cannot be changed by applying Windows cursor themes in the system Control Panel. Their shape and 3D shades and even size may differ from system's cursor set. So how do you define "correct XXXXX cursor for the platform", if simply there's no such system cursor? And remember: three of the above mentioned nine non-system cursors were fixed as Bug 163174. No one opposed there. They're in nightlies already! What makes this feature worse here, what makes this bug invalid? The fact that we have no system context-menu cursor in Windows? But there was no system cursor for vertical-text as well, and it did not stop the development of patches for Bug 163174. There's no solid logic if some of there cursors (originally equal) are fixed and some are not. Let's fix'em all! And how are you going to fix bug 1996 (which depends on this bug), if you wontfix this bug? The spec on http://www.w3.org/TR/html4/struct/objects.html reads, "Since an IMG element may be within the content of an A element, the user agent's mechanism in the user interface for accessing the "longdesc" resource of the former must be different than the mechanism for accessing the href resource of the latter." -- so, guessing from this text, we have to indicate the presence of londesc, and if it "MUST be different", then it MUST NOT be a standard pointer cursor if an IMG element is outside of an A element. [Here I use the key words "MUST" and "MUST NOT" as defined in RFC 2119 http://www.ietf.org/rfc/rfc2119.txt etc.] The mechanism proposed in bug 1996 is an additional item in Firefox context menu, so using context-menu cursor for areas with longdesc seems the most natural way of indication. If this bug bug is wontfixed, then bug 1996 will be pulled to be fixed less naturally, the solutions will tend to become more pervert -- a typical Bad Thing.

And a few more words about the spec: yes, the UA may treat unsupported values as 'auto'. (And Mozilla does.) However, this bug is to make the value 'context-menu' supported, so this portion of specs is not related to the afterfix state of UA.

And even more to mention: yes, on platforms that do not have a concept of a 'context-menu' cursor, the UA may render 'default' or whatever is appropriate. But that's only MAY -- neither SHOULD, nor MUST. So there's no obligation intended! Again, see RFC 2119 for details.

There's now (still?) another problem. Even if the context menu won't be implemented, it should remain at the default; however, it actually takes on the last cursor type, which is *very wrong*. See the demo at https://developer.mozilla.org/en/CSS/cursor.

Yeah, that looks wrong. Please file a new bug in Core/Widget:win32 and CC me.

IE 10 and Opera 12 on Windows 8 implements cursor:context-menu. Chrome 18 on Windows 8 does not. I think we should follow MS lead and implement it, they decide what is appropriate for the Windows platform after all.

This needs a CSS spec change, right?

(In reply to Boris Zbarsky (:bz) from comment #27) > This needs a CSS spec change, right? Why? http://www.w3.org/TR/2004/CR-css3-ui-20040511/#cursor describes 'context-menu'.

Uh... then why did this get wontfixed? Anyway, never mind me.

Btw. currently (FF 13.0.1) there's a bug related to this: Bug 712105 Sebastian