Bug 1497505 - Update the accesskeys of the bookmark tab(s) and (un)pin tab(s) to make them consistent regardless of the state. r?flod
46 bytes, text/x-phabricator-request
|Details | Review|
Some access keys shown in context menu are different depending on context. It's very confusing... Access key for bookmark: Single tab: Bookmark [T]ab But if multi tabs are selected: Boo[k]mark Tabs -> should be both [B]ookmark? Accesskey for mute/unmute: [M]ute Tab / Un[m]ute Tab Thou access key for pin/unpin: [P]in Tab / Unpin Ta[b] -> should be Un[p]in?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
7 months ago
Assignee: nobody → jaws
Status: NEW → ASSIGNED
I have not changed the entity names since the meaning of the strings has not changed.
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/6bfe39bf5e4d Update the accesskeys of the bookmark tab(s) and (un)pin tab(s) to make them consistent regardless of the state. r=flod
The bookmark and pin changes are ok on both nightly 65.0a1 (2018-11-11) and 64.0b8. Verified over macOS10.14, Win10, Ubuntu16.04. Bookmark - B Pin/Unpin - P While verifying the changes; the mute/unmute case mentioned by the reported seems to be overlooked. Is that intended? The issue would still be: Unmute ta[b]s / M[u]te tabs. There would still be a scenario where the B key would toggle between the unmute and bookmark option if the tab is already muted.
Thanks for catching that. Can you please file a bug to fix the the "Unmute tabs" and "Mute tabs" accesskey?
Hello all, Confirming as verified fixed on the latest Nightly Nightly 65.0a1(2018-11-22)and the latest Beta 64.0b12. Verified on Win10x 64, Ubuntu 16.04 and macOS 10.12.6.
You need to log in before you can comment on or make changes to this bug.