Closed Bug 258960 (context-menu-cursor) Opened 20 years ago Closed 2 years ago

'context-menu' cursor glyph missing for Windows

Categories

(Core :: Widget: Win32, defect)

x86
Windows XP
defect
Not set
minor

Tracking

()

RESOLVED WONTFIX

People

(Reporter: MatsPalmgren_bugz, Unassigned)

References

(Blocks 1 open bug, )

Details

(Keywords: css3, helpwanted, Whiteboard: [read comment 2 before checkin])

Attachments

(2 files)

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
Keywords: helpwanted
Blocks: 258966
Keywords: css3
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)
Whiteboard: [read comment 2 before checkin]
Blocks: 163174
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.
Attachment #169071 - Attachment mime type: image/x-mswindows-cursor → image/x-icon
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.
Blocks: longdesc
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.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WONTFIX
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)
Keywords: qawanted
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.
Blocks: 280331
Product: Core → Core Graveyard
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.
Assignee: win32 → nobody
Status: RESOLVED → REOPENED
Component: GFX: Win32 → Widget: Win32
Keywords: qawanted
Product: Core Graveyard → Core
QA Contact: ian → win32
Resolution: WONTFIX → ---
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
Alias: context-menu-cursor

(In reply to Mats Palmgren (inactive) from comment #26)

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.

Microsoft Edge on Windows 11 does not currently have cursor:context-menu implemented, therefore closing this bug again.

Status: REOPENED → RESOLVED
Closed: 20 years ago2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.