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

Add hotkey to code block button #37

Merged
merged 5 commits into from
Mar 22, 2021
Merged

Conversation

aaron-tdouble
Copy link
Contributor

Description

This PR does the following:

  • adds a hotkey of C for the MarkdownCodeButtonElement
  • forces hotkeys to be case sensitive

Issue

References: https://github.com/github/special-projects/issues/135

Screenshots

Demonstrating the current behavior of hotkeys not being case sensitive:

Screen Cast 2021-03-18 at 1 16 40 PM

Risk Assessment

Low risk

@relph
Copy link

relph commented Mar 18, 2021

adds a hotkey of C for the MarkdownCodeButtonElement

@aaron-tdouble in chrome the shortcut cmd+shift+C opens dev tools. Will this conflict with that? Or when you're writing MD and focused in the text field will cmd+shift+C insert the code block and when not focused it'll continue to open dev tools?

Also, can we add the new shortcut to the tooltip that appears when hovering on the code icon in the markdown toolbar? Similar to bold:

Screen Shot 2021-03-18 at 11 35 46 AM

@aaron-tdouble
Copy link
Contributor Author

aaron-tdouble commented Mar 18, 2021

in chrome the shortcut cmd+shift+C opens dev tools. Will this conflict with that? Or when you're writing MD and focused in the text field will cmd+shift+C insert the code block and when not focused it'll continue to open dev tools?

@relph Correct! Because it is intercepting the event in the text area, it does not open dev tools.

Also, can we add the new shortcut to the tooltip that appears when hovering on the code icon in the markdown toolbar?

Absolutely! That change will happen inside the monorepo in a subsequent PR.

Comment on lines +397 to +398
const key = event.shiftKey ? event.key.toUpperCase() : event.key
const button = findHotkey(toolbar, key)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this change is needed. I can revert this block locally and the tests still run green.

The case-sensitivity is already backed in since we do strict equality of the key pressed and the hotkey attribute.

Copy link
Contributor Author

@aaron-tdouble aaron-tdouble Mar 19, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@koddsson I must be doing something wrong because this test (correctly) fails for me on main.

Copy link
Contributor Author

@aaron-tdouble aaron-tdouble Mar 19, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does it do for you on the example page?

If I cmd-b or cmd-B (cmd-shift-b), it bolds the text. I would expect it only to respond to a lowercase b.

This is true for me on Chrome, Safari, and Firefox. Also true for someone that used Microsoft Edge browser on Mac.

Copy link
Contributor Author

@aaron-tdouble aaron-tdouble Mar 19, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@koddsson Wait. Scratch my first comment above. I was testing the wrong thing. Let me look into that in the morning, but my second comment ☝️ still stands. I'm curious how this behaves for you.

I agree with you that it should work as written. All the docs I read say that key will always return the actual key being pressed (as in, the uppercase B or lowercase b), but when I inspect the event in the debugger, I never see an uppercase letter for key.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does it do for you on the example page?

If I cmd-b or cmd-B (cmd-shift-b), it bolds the text. I would expect it only to respond to a lowercase b.

+B is a global shortcut on my mac that launches a application 😄

But yeah if I turn that off then I can bold with both. This is unexpected but apparently, if you are holding the meta key down KeyboardEvent.key will always be lowercase.

I made a little site to test out the keydown handler here.

Getting the tests to fail when this block is removed would be good though 👍🏻

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh yeah... this is a specific edge case with macos reporting lower case keys for specifically cmd+shift. See https://bugs.webkit.org/show_bug.cgi?id=174782 & https://bugs.chromium.org/p/chromium/issues/detail?id=747358

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good finds and information, @koddsson and @keithamus. I'll work on getting a breaking test on this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@koddsson
Copy link
Contributor

in chrome the shortcut cmd+shift+C opens dev tools. Will this conflict with that? Or when you're writing MD and focused in the text field will cmd+shift+C insert the code block and when not focused it'll continue to open dev tools?

@relph Correct! Because it is intercepting the event in the text area, it does not open dev tools.

I never use this shortcut but this feels like this is unexpected behavior. I wonder if users will get upset if we override their browser shortcuts.

On macOS, there is an existing bug that will always
report the keydown event.key as lowercase, even
when pressing cmd-shift-letter.

This can result in the toolbar hotkey firing for
both the uppercase and lowercase meta keys.  This
was fixed in a prior commit, but a test is being
added here to emulate this behavior in the test,
so that there is a “breaking” regression test.
@aaron-tdouble
Copy link
Contributor Author

aaron-tdouble commented Mar 19, 2021

I never use this shortcut but this feels like this is unexpected behavior. I wonder if users will get upset if we override their browser shortcuts.

I think this is a good question to raise. @relph or @siminapasat do you want to weigh in here?

On one hand, I have all kinds of tools installed that override some default shortcuts. (In fact, I had to install ShortcutDetective just to figure out why cmd-C wasn't initially working for me in this PR. It was due to ColorSlurp.)

The difference is that I chose to install those apps, even if I didn't know it was going to hijack those shortcuts. In this case, we are in some ways forcing the shortcut on the user.

On the other hand, this (1) is very isolated to having focus in the textarea element and (2) seems to be a common keystroke for insertion of code blocks. For some users, this will be a net good thing™.

Thoughts, opinions?

@koddsson
Copy link
Contributor

On the other hand, this (1) is very isolated to having focus in the textarea element and (2) seems to be a common keystroke for insertion of code blocks. For some users, this will be a net good thing™.

I buy that argument. Finding a shortcut that isn't used by any other application is tricky.

If we could somehow avoid this one since it's used a lot by developers and they make up the majority of our users I think that could be great but I'll default to you here.

@relph
Copy link

relph commented Mar 19, 2021

On the other hand, this (1) is very isolated to having focus in the textarea element and (2) seems to be a common keystroke for insertion of code blocks. For some users, this will be a net good thing™.

I was going to argue for this ☝️ but Chrome being by far the most popular browser used by developers I have a feeling we might be adding friction to a lot of peoples workflow. Feels easily avoidable. What if instead we follow notions lead and use ⌘+E

Screen Shot 2021-03-19 at 8 34 58 AM

Thoughts?

@aaron-tdouble
Copy link
Contributor Author

@relph I'm good with ⌘+E and since we will have toolbar hover help, there will be some user nudging.

@aaron-tdouble
Copy link
Contributor Author

@koddsson @keithamus I changed the keyboard shortcut to ⌘+E for code blocks. Let me know if you have any other concerns or need anything else in order to merge this. Thanks!

Copy link
Contributor

@koddsson koddsson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me! ✨

Copy link
Member

@keithamus keithamus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed! 👍

@keithamus keithamus merged commit df9c592 into main Mar 22, 2021
@keithamus keithamus deleted the td/add-hotkey-to-code-button branch March 22, 2021 10:27
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 this pull request may close these issues.

4 participants