1475851 - OS-specific XUL access key attribute documentation wrong

Status: RESOLVED WONTFIX

(Developer Documentation Graveyard :: General, enhancement, P5)

Description

[Thomas D. (:thomas8)]

:: Developer Documentation Request

      Request Type: Correction
     Gecko Version: unspecified
 Technical Contact: 

:: Details

https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Attribute/accesskey

The OS-specific XUL access key information on this page is just wrong, quite totally wrong:

> On non-Macintosh platforms, the character on the element's label matching the accesskey
> is underlined. For example, when a menu labeled 'File' has an accesskey of 'F', the
> generated label will be 'File'. When the user presses a modifier key specific to the
> platform (eg, Control* on Windows, Command* on Macintosh) and the access key, the
> element will be focused and/or activated from anywhere in the window. On the Macintosh,
> labels are never underlined, however accesskeys can still be used by pressing the letter
> combined with the Command key.
> *(These are the keys corresponding to event.ctrlKey and event.metaKey respectively when
> listening to key events)

Definitely for Windows, Ctrl+F in a XUL window is NOT the access key for File Menu, but a *shortcut* key for Find.
Also on Macintosh, it's quite unlikely to be Command+F for File Menu, that's Find also. On Mac, making application access keys Command+* would rapidly break loads of default shortcut keys on the MAC. And I've read other documentation that XUL access keys have no effect on MAC (can't find that right now), which seems more likely.
So event.ctrlKey and event.metaKey are also not related to access keys.

Comment 1

[Thomas D. (:thomas8)]

Access key documentation is also incomplete elsewhere:

https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Attribute/modifiers

> access: The access key for activating menus and other elements.
>         On Windows, this is the Alt key, used in conjuction with an element's accesskey.

And then? What about Linux and MAC OS? (On Linux, I think modifier="access" also translates to ALT, don't know for MAC OS, probably ineffective, or maybe Control?)

Comment 2

[Thomas D. (:thomas8)]

(In reply to Thomas D. (currently busy elsewhere) from comment #1)
> Access key documentation is also incomplete elsewhere:
> 
> https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Attribute/modifiers
> 
> > access: The access key for activating menus and other elements.
> >         On Windows, this is the Alt key, used in conjuction with an element's accesskey.
> 
> And then? What about Linux and MAC OS? (On Linux, I think modifier="access"
> also translates to ALT, don't know for MAC OS, probably ineffective, or
> maybe Control?)

Moreover, using modifiers="access" breaks the keytext of menu items associated via key-id (access key not converted into OS access key and hence missing in the keytext), which should be filed as a bug if there isn't one yet and noted in documentation until that bug is fixed.

Comment 3

[Thomas D. (:thomas8)]

(In reply to Thomas D. (currently busy elsewhere) from comment #0)

> Definitely for Windows, Ctrl+F in a XUL window is NOT the access key for
> File Menu, but a *shortcut* key for Find.
> Also on Macintosh, it's quite unlikely to be Command+F for File Menu, that's
> Find also. On Mac, making application access keys Command+* would rapidly
> break loads of default shortcut keys on the MAC. And I've read other
> documentation that XUL access keys have no effect on MAC (can't find that
> right now), which seems more likely.
> So event.ctrlKey and event.metaKey are also not related to access keys.

The above are just examples/hints to show that current documentation is wrong. I think the author was not aware of the conceptual and technical difference between access keys and shortcut/command keys

Access keys:
* underlined characters in words in the UI which can be triggered with a predictable, fixed key combo
* no need to define modifier bc it's standardized (Alt+* on Win/Linux; not present on MAC OS)
* realized via <element accesskey="X"/>

Shortcut/command keys:
* free for apps to define within certain limits/flavors, e.g. Ctrl+F, Ctrl+Shift+F
* need to define modifiers, e.g. <key key="F" modifiers="Ctrl,Shift"/>
* realized via <key key="X" modifiers="..."/>

Here's the general picture (sketch of proposed corrections):

Access key combo on Windows is ALT+* (not Ctrl+* as claimed in current docs, that's a recommended standard for shortcut keys)
Access key combo on Linux is ALT+* (misssing in current docs)
MAC OS (afasics) does NOT support any access keys of that sort at all, only shortcut/command keys. (not Command+* as claimed in current docs, that's a recommended standard for shortcut keys).

Comment 4

[BMO Automation]

MDN Web Docs' bug reporting has now moved to GitHub. From now on, please file content bugs at https://github.com/mdn/sprints/issues/ and platform bugs at https://github.com/mdn/kuma/issues/.