1195437 - HTML accesskey should underline and navigate menu items

Status: NEW

(Core :: DOM: Core & HTML, defect, P5)

Description

[janekptacijarabaci]

User Agent: Opera/9.80 (Windows NT 6.1; WOW64) Presto/2.12.388 Version/12.17

Steps to reproduce:

https://hg.mozilla.org/mozilla-central/file/a6eeb28458fd/toolkit/locales/en-US/chrome/global/viewSource.properties#l16
- The letter "L".

https://hg.mozilla.org/mozilla-central/file/a6eeb28458fd/toolkit/components/viewsource/content/viewSource-content.js#l952
- The letter "L" causes the letter "L" to be underlined...

...but it will not happen and the accesskey doesn't work (the initial letter works).

Comment 1

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Is this the same issue as bug 1191033, as it works in the initial new tab created by view source, but then fails if you copy that view-source: URL to some existing tab?

Comment 2

[janekptacijarabaci]

Unfortunately, it's not the same problem (https://bugzilla.mozilla.org/show_bug.cgi?id=1191033#c7). It always does.

But it may be related to the bug 1191033.

Comment 3

[janekptacijarabaci]

Ad https://bugzilla.mozilla.org/show_bug.cgi?id=1191025
Now what is right? :-)

Comment 4

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

(In reply to janekptacijarabaci from comment #3)
> Ad https://bugzilla.mozilla.org/show_bug.cgi?id=1191025
> Now what is right? :-)

What do you mean by "the accesskey doesn't work (the initial letter works)"?  I understand that L seems to not work, but what letter does work?  Are you using a specific locale of Firefox?  We could check to see if context_goToLine_accesskey has been translated there, as in bug 1191025.

Comment 5

[janekptacijarabaci]

en_US: This works with the letter "G" (Go to Line…).

Comment 6

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

So you are pressing Alt-Shift-G to trigger to the Go to Line prompt on Windows?

Comment 7

[janekptacijarabaci]

After popup is opened - see attached the file "viewSource_popup.png".

> The letter "L" causes the letter "L" to be underlined...
> ...but it will not happen and the accesskey doesn't work (the initial letter works).
The initial letter = "G"
(no key combination, only the letter)

Go to Line… = accesskey="L" (it doesn't work)

Save Page As… = accesskey="P" (works)
Select All = accesskey="A" (works)
View Page Source = accesskey="V" (works)
View Page Info = accesskey="I" (works)
...

Comment 8

[janekptacijarabaci]

Attachment: viewSource_popup.png

Comment 9

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Ah, okay, I see what you mean now.

This is a difference between the meaning of "accesskey" when used in XUL elements vs. HTML <menuitem>s.

On XUL elements, it underlines a letter[1] as you were expecting and you can select the element by that letter.

On HTML <menuitems>, they currently only create a keyboard shortcut[2] for use from outside the menu itself.  The correct shortcut is based on the accesskey value, but differs per OS.

So, this is why bug 1191025 says the string should be named "commandkey", since that's more similar to the actual behavior in Gecko terminology.  HTML accesskeys behave like a XUL command's associated key shortcut, not like XUL accesskeys.

I believe the fact that the first letter of the label works ("G") here is only because that's the OS default behavior when no explicit access key is defined.

It's possible something like bug 704428 would improve this, but as I understand it this is a long standing issue with HTML accesskeys.

[1]: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Attribute/accesskey
[2]: https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/accesskey

Comment 10

[janekptacijarabaci]

> It's possible something like bug 704428 would improve this, but as I
> understand it this is a long standing issue with HTML accesskeys.

Thank you. I not found this bug report :-)