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).
Severity: normal → minor
OS: Unspecified → All
Priority: -- → P5
Hardware: Unspecified → All
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?
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.
Ad https://bugzilla.mozilla.org/show_bug.cgi?id=1191025 Now what is right? :-)
(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.
en_US: This works with the letter "G" (Go to Line…).
So you are pressing Alt-Shift-G to trigger to the Go to Line prompt on Windows?
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) ...
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 as you were expecting and you can select the element by that letter. On HTML <menuitems>, they currently only create a keyboard shortcut 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. : https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Attribute/accesskey : https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/accesskey
Status: UNCONFIRMED → NEW
Component: View Source → DOM: Core & HTML
Depends on: 704428
Ever confirmed: true
Product: Toolkit → Core
Summary: "Tools->Web Developer->Page Source" - "Go to Line…" item in popup menu - the accesskey doesn't work properly → HTML accesskey should underline and navigate menu items
> 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 :-)
You need to log in before you can comment on or make changes to this bug.