"Translate selection" context menu item has the same access key as "Send to device"
Categories
(Firefox :: Translations, defect)
Tracking
()
People
(Reporter: bytesized, Unassigned)
Details
Attachments
(1 file)
|
580.56 KB,
video/mp4
|
Details |
I am currently unable to merge a patch that would enable the "Send to Mobile"/"Send to Device" context menu entry by default because this test complains
FAIL test_strip_on_share_on_secure_about_page - menuitem context-translate-selection has same accesskey as context-sendlinktodevice
chrome://mochikit/content/browser-test.js:test_ok:1891
chrome://mochitests/content/browser/browser/base/content/test/contextMenu/contextmenu_common.js:getVisibleMenuItems:86
chrome://mochitests/content/browser/browser/base/content/test/contextMenu/contextmenu_common.js:checkMenu:240
chrome://mochitests/content/browser/browser/base/content/test/contextMenu/contextmenu_common.js:checkContextMenu:152
chrome://mochitests/content/browser/browser/base/content/test/contextMenu/contextmenu_common.js:test_contextmenu:445
chrome://mochitests/content/browser/browser/base/content/test/contextMenu/browser_contextmenu.js:test_strip_on_share_on_secure_about_page:2613
chrome://mochikit/content/browser-test.js:handleTask:1380
chrome://mochikit/content/browser-test.js:_runTaskBasedTest:1470
chrome://mochikit/content/browser-test.js:Tester_execTest:1621
chrome://mochikit/content/browser-test.js:nextTest/<:1360
chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:SimpleTest.waitForFocus/<:1060
And it is absolutely right. The access key for "Send to Device" and the access key for "Translate Selection" are both n.
Comment 1•4 months ago
|
||
I definitely see the conflict here in terms of access keys.
I would just like to understand better what this modified behavior is, and why it's only causing a conflict now. The Translations access key has been "stable" without any reported conflicts for 2 years, yet as per Bryan's comment in Slack, he said, "This can be fixed by making a change to the accesskey in the en-US string to an available key (likely the translation one since that came after the conflicting one)."
That makes me think that the access key that conflicts with Translations is pre-existing, but they just never used to show at the same time, and something is changing that is making them show at the same time?
I am personally fine with changing the access key for Translations if needed, as long as we can find one. But I am going to CC my product manager on this for further input.
:bytesized
Can you clarify the context on why there was no conflict in the past 2 years, but there is now?
:kbryant
Can you give your perspective on potentially changing the Translations access key to accommodate?
| Reporter | ||
Comment 2•4 months ago
|
||
(In reply to Erik Nordin [:nordzilla] from comment #1)
:bytesized
Can you clarify the context on why there was no conflict in the past 2 years, but there is now?
The test only examines visible menu items. Until now, the "Send to device" entry was only visible if the user is signed in, which the test does not simulate.
Comment 3•4 months ago
|
||
Question:
Is there anything fundamentally wrong with a shared access key (other than the test expectation)?
Functionally, it looks like pressing n multiple times toggles between the two, and both are fully functional.
See attached video for an example.
Comment 4•4 months ago
|
||
I had an LLM scan the code base for conflicts using all the letters of "Translate":
t/T:Open Link in New Tab,Take Screenshotr:Print Selection…a/A:Select Alln:Send Link to Device,Send Link to Mobiles/S: dynamicSearch <engine> for …l/L:Copy Linke:View Selection Source
It looks like n is only a conflict for "Translate Link Text..." and r is only a conflict for "Translate Selection..."
So we could, in theory, make the access key for "Translate Link Text..." be r, and let the access key for "Translate Selection..." remain n without any real conflict.
:kbryant, thoughts on this solution from an A11y perspective?
Comment 5•4 months ago
•
|
||
I think my preferred option would be to find out if it's okay to share. This behavior has been reproducible in release Firefox for all logged-in accounts for 2 years with no reported issues, and the "Send to device" option comes first.
Beyond that, I like the idea of changing "Translate Link Text..." to r and leaving "Translate Selection..." as n.
That would ensure that there are no conflicts.
Our link-text Translations only make up 3% of our total requests for the SelectTranslationsPanel, so this change would likely go largely unnoticed.
Quickly weighing in re: accessibility: we should try to keep as is/share if at all possible so we don't break users' muscle memory -- which causes friction/barriers for both our accessibility customers and users in general.
If we do have to change things, I'd pick a different letter pair than "r"and "n" so that users have an easier time visually differentiating them.
Comment 7•4 months ago
•
|
||
So, clarifying here for the original report:
- we should keep the overlap for Send Tab, and adjust the test -- yes?
Whether the two translate options get changed we can spin off into its own bug.
Comment 8•4 months ago
|
||
I think that keeping the current bindings would be my preference. They appear to be fully functional: pressing n toggles between the two of them within the menu. This behavior has been in the release channel for about 2 years, reproducible for any logged-in user. We only didn't know about it because our testing doesn't simulate being logged in.
I think that with the consideration of adding a brand-new access key, it would be inadvisable to intentionally overload they key with more than one option, but given that the behavior unintentionally pre-existed, and is clearly designed to function like this, I think it would be less disruptive to keep things as they are.
Comment 9•4 months ago
|
||
The severity field is not set for this bug.
:gregtatum, could you have a look please?
For more information, please visit BugBot documentation.
Updated•4 months ago
|
Description
•