Firefox: Keyboard shortcuts with modifier keys sometimes trigger browser functions

[Vectorial1024]

URL

N/A

How to reproduce the issue?

Currently, Ctrl+Shift+M can bring up the measurements panel, but sometimes, in Firefox, it triggers the browser "mobile mode" instead; see https://its.uri.edu/services/946442a2ab7e3cfcb0d9034469b32186c7fad400e8/simulating-a-mobile-environment-in-a-browser/ :

[...]

• Firefox
  • Open Responsive Design Mode via one of these methods:
    • Windows: CTRL+Shift+M / Mac: Cmd+Opt+M
      [...]

Screenshot(s) or anything else?

N/A

Which deployed environments do you see the issue in?

Released version at openstreetmap.org/edit

What version numbers does this issue effect?

2.30.4

Which browsers are you seeing this problem on?

Firefox

[1ec5]

Each of the Ctrl (Command on macOS) key combinations sometimes triggers browser functionality instead of the intended application-specific command, depending on what has keyboard focus. Another example is pressing Ctrl+B (⌘B) immediately after selecting a background layer, while keyboard focus is still on the radio button, or pressing Ctrl+S (⌘S) while focused on an input box.

Ironically, users also sometimes expect to be able to trigger the built-in browser functions using these key combinations: #10479 #8801. But probably no one expects a shortcut to sometimes trigger a browser function and sometimes trigger an iD command depending on keyboard focus. This is a very real usability issue; more consistently triggering the iD command would make some browser functions more difficult to access, but at least it would be more predictable.

I’m unsure of the root cause, but probably a good first place to look is whether we bind a keyboard shortcut handler to the entire page or to individual DOM elements, and whether any elements are being left unhandled.

[Vectorial1024]

Pardon my crude language, but I kinda notice some external websites have these "asshole" features where they override normal browser behavior to prevent e.g. right clicks or text selection in the hopes of preventing users from copying data away from the website (just use DevTools!).

If the argument is strong, then I see no problems with overriding normal browser behavior. In this GitHub issue, the argument is extra strong because the alternative of browser behavior of "Ctrl+Shift+M mobile mode" just does not make sense. Does the team intend the iD editor to be used on mobile phones? Should outdoor tablets be using the iD editor? Me as an outsider thinks this does not make sense since being on mobile is essentially missing out like over half of the features (e.g. press M to move items, press R to rotate items, etc.).

Then, in this view, this ambiguity is a problem.

[1ec5]

No argument there – we’ve already decided to override Ctrl+C and Ctrl+F with functions we think the user will be more likely to want in the context of a map editor. What you’re seeing is simply a bug that our key handling doesn’t seem to work when certain controls are focused.

[Deeptanshu-sankhwar]

Thanks for sharing the issue @Vectorial1024 @1ec5 , I was trying to reproduce the issue, I believe this issue is only existent for Windows. I am trying to reproduce it on my Mac, but for Mac the iD shortcut to open the measurement panel is Command + Shift + M, and to open the mobile view the Firefox shortcut is Command + Opt + M.

Since both are different, I believe its working fine for Mac, and we may wanna edit the issue description thereby?

[1ec5]

This is true regarding mobile mode, but other browser functions are similarly affected, as described in #10623 (comment).

[Vectorial1024]

@Deeptanshu-sankhwar Thanks for the info about Mac. Indeed, I was using Windows when I found this inconsistency, so yes, the issue info can be updated to be more accurate.

Edit: my apologies, but there was a race condition on my side when initially viewing this page (returning from system hibernation), and I didn't see this comment.