1612254 - Keyboard shortcut (cmd + ,) does not create subscript as it does in other browsers

Status: VERIFIED FIXED

(Firefox :: Keyboard Navigation, defect, P2)

Description

[Sarah]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:72.0) Gecko/20100101 Firefox/72.0

Steps to reproduce:

Reproduction:

1. Open Firefox
2. Go to drive.google.com
3. Open document in Google docs
4. Highlight character in google docs (such as the "2" in H20)
5. Press command + , (comma)

Actual results:

Command + , opens a new tab in firefox - about:preferences

Expected results:

Highlighted character should turn into a subscript

(this works in google docs in other browsers and is listed as the proper shortcut for a subscript; superscript, command + . works)

Comment 1

[Alexandra Martin]

Hi Sarah,

Thank you for submitting this report. I was able to reproduce the issue on Mac 10.14 with Firefox versions Release 72.0.2, Beta 73.0b11 and Nightly 74.0a1 (2020-02-02).

The problem couldn't be reproduced using "Ctrl" + "," on Windows 10 x64 and Ubuntu 18.04.3 LTS with Firefox versions Release 72.0.2, Beta 73.0b11 and Nightly 74.0a1 (2020-02-02).

I am assigning a component, so our developers can take a look.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:dao, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 3

[John Dai[:jdai]]

It seems that we have a Preferences keyboard shortcut (command-comma) only for MacOS[1] and it set to reserved="true" in bug 1381951 so that the event will no longer dispatch to content process. I notice Safari also has the same issue.

[1] https://searchfox.org/mozilla-central/rev/fca0be7e2cf2f922c9b927423ce28e8a04b3fd90/browser/base/content/browser-sets.inc#363-366

Comment 4

[John Dai[:jdai]]

It seems it's safe to remove reserved="true" for macOS's preferences keyboard shortcut and it still can open preferences in Gmail[1].

[1] See bug 1381951 comment 17

Comment 5

[John Dai[:jdai]]

Attachment: Bug 1612254 - Stop marking the preferences shortcut as "reserved" on mac;

Comment 6

[:Atoll]

To remind about a comment from bug 1381951 (aside from the regression itself), allowing JavaScript to bind this shortcut introduces a phishing opportunity for sites to spoof Firefox’s “it’s made of HTML” about:preferences, since Mac users are trained to expected that shortcut to open application preferences.

Comment 7

[Pascal Chevrel:pascalc]

Marking as wontfix for 74 as we are nearing the end of the beta cycle.

Comment 8

[Jens Stutte [:jstutte]]

April, will you find time for that patch? Thanks!

Comment 9

[April King [:April]]

Err, I just noticed this. I don't usually work on Firefox, but the patch looks fine to me and so I gave it an r+. That said, it's really outside my area of expertise, so you may want to have an additional eye take a quick glance at it.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d9b28e0aad5d
Stop marking the preferences shortcut as "reserved" on mac; r=April

Comment 11

[April King [:April]]

I would add that I know this is done for compatibility with a popular product and is in line with how Chrome works, but I still feel in my gut that GDocs is behaving poorly here.

I will add that Safari also does not do subscript, and cmd-, on Safari while Google Docs is open brings up Safari's preferences.

Comment 12

[:Gijs (he/him)]

(In reply to April King [:April] from comment #11)

I would add that I know this is done for compatibility with a popular product and is in line with how Chrome works, but I still feel in my gut that GDocs is behaving poorly here.

I will add that Safari also does not do subscript, and cmd-, on Safari while Google Docs is open brings up Safari's preferences.

I agree that it'd be better for gdocs not to conflict here, and the browser discrepancies (and thus somewhat of a minefield for web authors to work out which shortcuts they can/cannot use/override) are not great.

Anne, is shortcut-un-overrideable-ness-for-websites something we could try to standardize as part of the DOM spec? Is there prior art / conversation on that subject?

Comment 13

[Arthur Iakab [arthur_iakab]]

https://hg.mozilla.org/mozilla-central/rev/d9b28e0aad5d

Comment 14

[Anne (:annevk)]

https://github.com/w3c/uievents/issues/261 seems related (and that would also be the repository to use for any enhancements to keyboard events). HTML has an accesskey attribute that in principle browsers could expose in a variety of ways, including those not overlapping with builtins, but it does require sites to use it (and browsers to support it accurately), neither of which is really a thing I believe. Hope that helps a bit.

Comment 15

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:jdai, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Comment 16

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Release mgmt bot [:sylvestre / :calixte / :marco for bugbug] from comment #15)

The patch landed in nightly and beta is affected.
:jdai, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Talked with John, and also as what Julien marked, wontfix for 75.

Comment 17

[Alexandru Trif, Desktop QA [:atrif]]

Reproduced the issue using Firefox 74.0a1 (20200129213721) on macOS 10.12.
The issue is verified fixed using Firefox 76.0b5 (20200415234430) on macOS 10.12. CMD + , turns the highlighted character into a subscript.