1647373 - The access key of menus.create() is displayed twice when intl.menuitems.alwaysappendaccesskeys=True

Status: NEW

(WebExtensions :: Frontend, defect, P5)

Description

[fixmebug]

Attachment: test.zip

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0

Steps to reproduce:

Install English, Japanese, Chinese, and Taiwanese language packs in your browser.
Install the attached simple addon from about:debugging.
Open the context menu.
The access keys ((C), (D)) are displayed twice on the menu element. (A) and (B) are normal.
In Taiwanese language as well, it is displayed twice. is. Everything is fine in Chinese and English.

Actual results:

The access keys ((C), (D)) are displayed twice on the menu element. (A) and (B) are normal.

Expected results:

Only one access key should be displayed for each of all menu items in all languages.

Comment 1

[fixmebug]

Attachment: The access key ((C), (D)) is displayed twice in the element of the context menu.

Comment 2

[fixmebug]

Attachment: In Taiwanese language as well, it is displayed twice.

Comment 3

[fixmebug]

Attachment: Chinese is normal.

Comment 4

[fixmebug]

Attachment: English is also normal.

Comment 5

[Francesco Lodolo [:flod]]

ja and zh-TW, unlike zh-CN, have intl.menuitems.alwaysappendaccesskeys set to True. That means that accesskeys will be always displayed after a label.

That explains the different behavior. Still, I don't think there should be two accesskeys displayed.

Tentatively moving to WebExtensions.

Comment 6

[Rob Wu [:robwu]]

I thought that I had fixed this before in bug 1484914 . And I did, but only if the access key has been rendered at the end of the line: https://hg.mozilla.org/mozilla-central/rev/964610ef7e3f

In your test case, the access key is prepended at the front of the line. This does not match the convention of the other menu items, where the access key is at the right of the menu label.

I am inclined to close this bug because this seems to be working as intended. But if you give a good reason for putting the access key at the other end of the line, then I may reconsider. Why do you want to put the access key at the start of the menu label, instead of the end (like other menu items)?

Comment 7

[fixmebug]

In my case, the menu items have long titles, they are all of the same type, and they have regularity, so I made it because it is easy to see at the beginning. The access key itself also has regular characters such as 0 to 9 and A to Z. At the end of the line, you have to move your eyes greatly to search for the access key, which is difficult to find because the access keys are not aligned vertically. For example, when displaying the titles of tabs in the menu in the order of tab indexes.
I do not speak English, but I don't think that is explained in https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/menus/create. If it is by design, those who use this API must be properly informed. Not everyone knows the conventions of Mozilla. And I don't think it's appropriate that the behavior differs depending on the language.
In any case, I don't think developer.mozilla.org has enough explanations, and I don't think that the behavior changes depending on the language or that the access key is displayed twice is a good specification. Even if you write it at the beginning, if the specification is that it is displayed at the end of the line, the access key at the beginning should disappear.

Comment 8

[Rob Wu [:robwu]]

The extra access key at the end was introduced almost 2 decades ago in bug 54285. The intention was to ensure that the line under the access key always appeared under the letter of the access key, instead of a different word that coincidentally contained the same letter. The fix was to unconditionally append the access key to the menu label.

I'm supportive of improving the logic to not unnecessarily append an access key, for example if it already contains (&k) (with k being the access key). In the implementation, this means that we would replace the current "ends with" logic from bug 1484914 with "contains" @ https://searchfox.org/mozilla-central/rev/cfaa250d14e344834932de4c2eed0061701654da/layout/xul/nsTextBoxFrame.cpp#801

:flod, what do you think? Should we change the implementation to not unconditionally append (k) when the menu label already contains (k), even when intl.menuitems.alwaysappendaccesskeys=true?

Comment 9

[fixmebug]

If developer.mozilla.org had a clear explanation of the behavior, I didn't have to write this bug report. I would have added an access key at the end of the line following the explanation. In the description on developer.mozilla.org, I misunderstand that no matter where you write the access key, it will be displayed there. Because I'm using the Japanese version of Firefox. I think you should update developer.mozilla.org first.

Comment 10

[Francesco Lodolo [:flod]]

(In reply to Rob Wu [:robwu] from comment #8)

:flod, what do you think? Should we change the implementation to not unconditionally append (k) when the menu label already contains (k), even when intl.menuitems.alwaysappendaccesskeys=true?

I think that should be the expected behavior, yes.

If the label is (&k) SOMELABEL, there's an accesskey already available in the label, and it should be underlined. That's not different from, for example, a normal label with accesskey "&Enter".

Comment 11

[Rob Wu [:robwu]]

(In reply to fixmebug from comment #9)

If developer.mozilla.org had a clear explanation of the behavior, I didn't have to write this bug report. I would have added an access key at the end of the line following the explanation.

I have updated the documentation at https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/menus/create . I hope that this helps!

I'm also going to mark this as a good-first-bug, to allow contributors to make their first patch in Firefox. Fixing this bug is rather easy, the patch would be similar to the one in bug 1484914 (https://hg.mozilla.org/mozilla-central/rev/964610ef7e3f), except instead of searching at the end of the menu label, one would need to search anywhere in the menu label.

Comment 12

[fixmebug]

(In reply to Rob Wu [:robwu] from comment #11)

I have updated the documentation at https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/menus/create . I hope that this helps!

In some localized versions of Firefox (Japanese and Chinese),

It is Taiwanese, not Chinese. In Chinese this does not happen.
It's a little off topic, but I'm wondering why Chinese and Taiwanese behave differently. As far as I know, both languages have the same grammar and the only difference is whether Kanji is traditional or simplified. I don't think there is a big difference in notational conventions.

Comment 13

[Rob Wu [:robwu]]

Tim, question to your past-self from a decade ago (https://hg.mozilla.org/l10n-central/zh-TW/annotate/e132dab80d36344bf4a9569ae021c50f593d2660/toolkit/chrome/global/intl.properties#l37):
Why does zh-TW have the intl.menuitems.alwaysappendaccesskeys pref set to true but zh-CN does not? This inconsistency is surprising (see also comment 12).

The only locales with this pref set to true by default are ja and zh-TW:
https://transvision.mozfr.org/string/?entity=toolkit/chrome/global/intl.properties:intl.menuitems.alwaysappendaccesskeys

Comment 14

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Attachment: Chinese Traditional Windows.zip

Hi Rob,

I am glad I left enough keywords in the commit message!

I am not sure about how Windows and Linux programs label their access keys nowadays, but I vaguely remember at the time the convention was to always append the key with parenthesis.

The changed was prompted by a localization QA report, sent to me from Multilingual QA on May 27, 2009. Multilingual QA was a company Mozilla contracted back in Firefox 3.5B4 to support localization team work. They did a QA run on the localized Firefox to spot any errors etc.

Many of the issues on the report was about missing access key. For example, they asked the menu item "允許網站設定 Cookie“ with accesskey "C" to be shown as "允許網站設定 Cookie (C)“. Please refer to the attached zip file, dug up from my mailbox. The example is issue #52 in the included Excel sheet. They have also included the screenshots.

Hope this helps! Thanks for the ping.

Please needinfo :petercpg if you would like to discuss zh-TW l10n repo changes. He owns the project since.

Comment 15

[Rob Wu [:robwu]]

(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #14)

Many of the issues on the report was about missing access key. For example, they asked the menu item "允許網站設定 Cookie“ with accesskey "C" to be shown as "允許網站設定 Cookie (C)“. Please refer to the attached zip file, dug up from my mailbox. The example is issue #52 in the included Excel sheet. They have also included the screenshots.

I see, in Windows/Bug Screenshot - Windows/zh-TW38.jpg. It does unfortunately not explain why it's necessary to have (C) instead of the underscore under the Cookie (like almost every other locale).

Please needinfo :petercpg if you would like to discuss zh-TW l10n repo changes. He owns the project since.

Thanks, will do.

Comment 16

[Rob Wu [:robwu]]

Hi Peter, do you know the answer to the question in comment 13 ?

Comment 17

[Francesco Lodolo [:flod]]

Sorry, I don't understand why we're having this conversation about zh-TW vs zh-CN in this bug.

This is an issue that needs to be solved independently (Japanese is another locale using that pref), so I'd suggest to move the zh-* conversation in a different bug (assuming there's actually need for one).

Comment 18

[Peter Pin-Guang Chen [:petercpg] (MozTW.org)]

(In reply to Rob Wu [:robwu] from comment #16)

Hi Peter, do you know the answer to the question in comment 13 ?

This was set before my epoch and I think Tim explained the story :)

Reading through the screenshots, I would assume the intention to move accesskey to suffix instead of underscore was for consistency in the UI. zh-TW30.jpg could be another example, as a user I am more comfortable to have access key in the end of checkbox in this specific view.

Or maybe the QA team did not aware that in-string-underscore was not a issue.

(In reply to fixmebug from comment #12)

It's a little off topic, but I'm wondering why Chinese and Taiwanese behave differently. As far as I know, both languages have the same grammar and the only difference is whether Kanji is traditional or simplified. I don't think there is a big difference in notational conventions.

The grammar is the same, but in this case I would say there's not much difference between CJK or even all non-latin locales.

It's not set based on language or grammar, but more like each locale's custom and preference.

Comment 19

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Francesco Lodolo [:flod] (OOO until July 20) from comment #17)

Yes, we should move this conversation to another bug.

(In reply to Peter Pin-Guang Chen [:petercpg] (MozTW.org) from comment #18)

Reading through the screenshots, I would assume the intention to move accesskey to suffix instead of underscore was for consistency in the UI. zh-TW30.jpg could be another example, as a user I am more comfortable to have access key in the end of checkbox in this specific view.

Or maybe the QA team did not aware that in-string-underscore was not a issue.

Let's not discuss what's comfortable for each of us, instead stick to the convention of the operating system.

Comment 20

[Shulammite]

Hello Rob Wu, I am an Outreachy applicant and I'd like to work on this project

Comment 21

[Falguni Islam]

Hello, I am new to contributing to Bugzilla can you assigned me to this issue so that I can learn to fix these bugs and also suggest to me how can Is start working on this bug to fix it