Skip to content

refactor(platform-browser): Updates keyboard event library to support code field #46030

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.

Sign up for GitHub

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

Jump to bottom
Closed
wants to merge 1 commit into from
Closed

refactor(platform-browser): Updates keyboard event library to support code field #46030

wants to merge 1 commit into from

Conversation

jessicajaniuk
Copy link
Contributor

@jessicajaniuk jessicajaniuk commented May 17, 2022 •
edited
Loading

PR Checklist

Please check if your PR fulfills the following requirements:

PR Type

What kind of change does this PR introduce?

  • Bugfix
  • Feature
  • Code style update (formatting, local variables)
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • CI related changes
  • Documentation content changes
  • angular.io application / infrastructure changes
  • Other... Please describe:

What is the current behavior?

Right now we only ever rely on the keyboardEvent key field, which is
limiting to users as far as matching keyboard events across OS and
different keyboard layouts. The alt / option key behavior with MacOS
is a specific issue.

Issue Number: resolves #45992

What is the new behavior?

On MacOS, pressing the alt key and another key turns into symbols, and
doesn't match the intended behavior. For example, keydown.alt.s
reports instead as keydown.alt.ß. We rely on the key field and not
the code field, which properly reports the code for S in this case.

This change adds support to allow users to specify they want to look at
the code field instead of the key field within their event string.
Example: keydown.code.alt.leftshift would only match the LeftShift and
not the right shift based on code values. It would also allow the user
to specify keydown.code.alt.keys to match S instead of ß when alt /
option is pressed on MacOS and would also work on Windows.

The proposed structure is {event}.{type}.{optional modifier}.{key/code}.
Alternatively we could do {event}.{optional modifier}.{type}.{key/code}.

Does this PR introduce a breaking change?

  • Yes
  • No

Other information

@jessicajaniuk jessicajaniuk added area: core Issues related to the framework runtime target: patch This PR is targeted for the next patch release labels May 17, 2022
@ngbot ngbot bot added this to the Backlog milestone May 17, 2022
AndrewKushnir
AndrewKushnir reviewed May 17, 2022
View reviewed changes
Copy link
Contributor

@AndrewKushnir AndrewKushnir left a comment

Choose a reason for hiding this comment

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

Looks awesome! 👍

I'd like to propose a couple options for consideration:

  • use code right in front of the char, i.e. keydown.alt.code.keys - this might be a bit easier to explain: the code. is applied to the char that follows it immediately. With the current format, there might be an ambiguity on whether code applies to alt (and other modifiers).
  • extract code modifier to a specially designated place: keydown.alt.keys:code, so the format of the event key remains the same and the :code applies to the last bit of the event key (i.e. 'keys').

packages/platform-browser/src/dom/events/key_events.ts Outdated
Comment on lines 136 to 161
if (keycode === ' ') {
keycode = 'space'; // for readability
} else if (keycode === '.') {
keycode = 'dot'; // because '.' is used as a separator in event names
}
Copy link
Contributor

Choose a reason for hiding this comment

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

I think it'd be awesome to detect a situation when this is actually used and produce a console.warn in the ngDevMode and suggest to use a code. approach instead (and actually deprecate those special cases and eventually remove).

@jessicajaniuk jessicajaniuk force-pushed the key-bindings branch 4 times, most recently from 99eec8e to 3c81e86 Compare May 18, 2022 16:09
@jessicajaniuk jessicajaniuk added the action: review The PR is still awaiting reviews from at least one requested reviewer label Jul 11, 2022
@jessicajaniuk jessicajaniuk force-pushed the key-bindings branch 3 times, most recently from 9599cbc to 6e6eb64 Compare July 12, 2022 00:02
@dylhunn dylhunn self-requested a review July 13, 2022 07:44
dylhunn
dylhunn approved these changes Jul 13, 2022
View reviewed changes
Copy link
Contributor

@dylhunn dylhunn left a comment •
edited
Loading

Choose a reason for hiding this comment

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

This looks basically good to me. I have no preference on the design questions Andrew K posed above, although you'll likely want to settle that before merging. This deletes a bunch of code too, which is awesome!

reviewed-for: fw-core, size-tracking

@jessicajaniuk jessicajaniuk mentioned this pull request Jul 13, 2022
Closed
@jessicajaniuk jessicajaniuk force-pushed the key-bindings branch 3 times, most recently from cee7b7c to 8606fbe Compare July 13, 2022 16:40
AndrewKushnir
AndrewKushnir reviewed Jul 14, 2022
View reviewed changes
Copy link
Contributor

@AndrewKushnir AndrewKushnir left a comment

Choose a reason for hiding this comment

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

@jessicajaniuk the change looks great 👍 Special thanks for adding tests as well (for new and existing key patterns)!

In the current implementation the code. is a prefix for the entire event name, for ex. : code.alt.meta.KeyS. When there are some modifiers, the code. and the actual key code are separated by those modifiers. I was thinking if a possible option might be to colocate the prefix and the code like this: alt.meta.code.KeyS. WDYT?

@jessicajaniuk
Copy link
Contributor Author

@AndrewKushnir My personal preference is the proposed structure with {event}.{type}.{optional modifier}.{key/code}. To me it sort of groups more logically for me. Event / type followed by key combinations. I think it reads more clearly.

AndrewKushnir
AndrewKushnir approved these changes Jul 14, 2022
View reviewed changes
Copy link
Contributor

@AndrewKushnir AndrewKushnir left a comment •
edited
Loading

Choose a reason for hiding this comment

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

LGTM, thanks for implementing this feature! 👍

Discussed offline: I'm happy with both code.alt.KeyS and alt.code.KeyS, so my feedback is not a blocker.

One additional comment: it'd be great to find a good place in our docs to add an example of a keyboard event binding using code (and may be also describe when it makes sense to use it). This is also not a blocker and we can do it after this PR lands.

Reviewed-for: size-tracking, public-api

@jessicajaniuk
Copy link
Contributor Author

@AndrewKushnir I've updated method comments to clarify the order of what happens with the methods here and how normalization of the event string occurs for internal processing. I've also added test cases for placing code in various parts of the event string from a user perspective to make the flexibility of ordering clearer when defining the event string.

@jessicajaniuk jessicajaniuk added action: merge The PR is ready for merge by the caretaker action: global presubmit The PR is in need of a google3 global presubmit and removed action: review The PR is still awaiting reviews from at least one requested reviewer labels Jul 14, 2022
@jessicajaniuk jessicajaniuk added target: minor This PR is targeted for the next minor release state: blocked and removed target: patch This PR is targeted for the next patch release action: merge The PR is ready for merge by the caretaker action: global presubmit The PR is in need of a google3 global presubmit labels Jul 15, 2022
@thePunderWoman
refactor(platform-browser): Updates keyboard event library to support…
a275fb0 
… code field

On MacOS, pressing the alt key and another key turns into symbols, and
doesn't match the intended behavior. For example, `keydown.alt.s`
reports instead as `keydown.alt.ß`. We rely on the `key` field and not
the `code` field, which properly reports the code for S in this case.

This change adds support to allow users to specify they want to look at
the `code` field instead of the `key` field within their event string.
Example: `keydown.code.alt.leftshift` would only match the LeftShift and
not the right shift based on code values. It would also allow the user
to specify `keydown.code.alt.keys` to match S instead of ß when alt /
option is pressed on MacOS and would also work on Windows.

Fixes angular#45992
@jessicajaniuk jessicajaniuk added action: global presubmit The PR is in need of a google3 global presubmit action: merge The PR is ready for merge by the caretaker and removed state: blocked action: global presubmit The PR is in need of a google3 global presubmit labels Jul 15, 2022
@jessicajaniuk
Copy link
Contributor Author

Passing TGP as of this morning.

@jessicajaniuk
Copy link
Contributor Author

This PR was merged into the repository by commit a67a8b2.

@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Aug 18, 2022
@jessicajaniuk jessicajaniuk deleted the key-bindings branch January 27, 2023 16:42
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Reviewers

@dylhunn dylhunn dylhunn approved these changes

@AndrewKushnir AndrewKushnir AndrewKushnir approved these changes

Assignees
No one assigned
Labels
action: merge The PR is ready for merge by the caretaker area: core Issues related to the framework runtime target: minor This PR is targeted for the next minor release
Projects
None yet
Milestone
Backlog
Development

Successfully merging this pull request may close these issues.

Specific keys binding on MacOs should work
4 participants
@jessicajaniuk @dylhunn @AndrewKushnir @thePunderWoman