Navigation Menu

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mac Keyboard Shortcut Conflict: Tilde and New Toot #14862

Closed
benhamill opened this issue Sep 23, 2020 · 4 comments · Fixed by #14942
Closed

Mac Keyboard Shortcut Conflict: Tilde and New Toot #14862

benhamill opened this issue Sep 23, 2020 · 4 comments · Fixed by #14942

Comments

@benhamill
Copy link

There is a conflict between the keyboard shortcut for starting a new toot (alt-n) and the way macOS allows users to add a tilde diacritic to characters (e.g. you can type "ñ" with alt-n n or "õ" with alt-n o). The result is that trying to type, say, the word "español" in the input box ends up with just "ñol". This seems like a big bother for localization for folks who use US keyboards, but want to type Spanish (or other languages that use this diacritical mark).

Expected behaviour

When any text input box is focused, typing alt-n will append a ˜ to your existing input so you can pick a character for it to modify (standard macOS behavior).

Actual behaviour

When the new toot text box is focused, typing alt-n clears the existing input before the ˜ is inserted and you can pick a character for it to modify.

Steps to reproduce the problem

  1. Begin composing a new toot.
  2. Type e s p a alt-n n o l.
  3. Observe that the characters "espa" were deleted when alt-n was pressed.

Specifications

Firefox 80.0.1. MacOS Mojave 10.14.6. I expect this will happen across a wide variety of browsers and versions of macOS because alt-n has been the tilde shortcut for the OS for a long time. I'm not sure if there's a way for random users to get their instance's version of Mastodon, but I'm on eldritch.cafe and I think it's pretty up-to-date.

@benhamill
Copy link
Author

As a follow-up, on macOS, alt is used in combination with a lot of different keys to get a wide range of useful characters. E.g. alt-e i is "í", alt-; is "…", alt-2 is "™" and alt-8 is "•" just to name some of the ones I personally use very often. So I think rather than thinking of alt-n as a special case, it might be better to approach this from a standpoint of bypassing all the alt-based keyboard shortcuts when a text box is focused so as not to interrupt typing.

@TixieSalander
Copy link

Same situation here (also on Firefox MacOS), pretty annoying.

Also if it can help, I've tried on Chromium 86 and Safari 14 and I don't have the issue, only on Firefox (83).

ClearlyClaire added a commit to ClearlyClaire/mastodon that referenced this issue Oct 5, 2020
Fixes mastodon#14862

This used to be the case until mastodon#13987, which introduced a hotkey to toggle
the Content Warning field.

Unfortunately, MacOS relies on the “alt” key for many things, including
composing text (see mastodon#14862), therefore, even if that makes the CW toggle
hotkey significantly less useful, it makes sense to not interfere with
composing toots.
@miramarco
Copy link

I can confirm this behaviour on Firefox 81.0.1, also on Mojave, and on a Mastodon instance running v3.2.0.

I could find only one other documented alt-based hotkey: alt-x, which shows/hides the CW field, but it also corresponds to † on some macOS keyboards (I am using the Italian one). Differently from alt-n, the † cannot be typed in at all, whereas ˜ does show up as the first character of the new toot.

Gargron pushed a commit that referenced this issue Oct 5, 2020
Fixes #14862

This used to be the case until #13987, which introduced a hotkey to toggle
the Content Warning field.

Unfortunately, MacOS relies on the “alt” key for many things, including
composing text (see #14862), therefore, even if that makes the CW toggle
hotkey significantly less useful, it makes sense to not interfere with
composing toots.
@benhamill
Copy link
Author

Yay! Thanks, @ThibG! 💖

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants