☂️ Device-specific keyboard events should happen in the embedder

[gspencergoog]

In order to make implementing #33521 easier, and because it is a better factoring of the code, it makes sense to have the embedding side translate the local key events into a generic representation that the framework can then pass along.

This could be done by moving all of the keyboard key translation to the engine side, normalize it there, and just send a generic key event to the framework.

This would be a large breaking change on the framework side to remove the ability to look at the raw key event data on the framework side, but that is a fairly uncommon operation. We would have to make sure that we encoded all the relevant information in the generic key event (key repeat counts, left/right modifier information, etc.).

[gspencergoog]

cc @stuartmorgan

[gspencergoog]

Here's the current design doc for this: https://flutter.dev/go/platform-based-key-events

[dkwingsmt]

Progress

• Embedder and Web: Hardware keyboard: Web, embedder, and dart:ui engine#23466
• Framework
  • Make LogicalKeyboardKey.keyLabel a getter and better Make LogicalKeyboardKey.keyLabel a getter and better #79100
  • Shortcut activator Shortcut activator #78522
  • Events: Keyboard events #83752
• Windows: Hardware Keyboard: Windows engine#23465
• Android:
  • Manager: [Android KeyEvents] Split AndroidKeyProcessor into separate classes engine#25628
  • Embedder responder: Hardware Keyboard: Android engine#33113
• iOS: Hardware Keyboard: iOS engine#25961
• Linux (GTK): Hardware Keyboard: Linux (GTK) engine#23467
• macOS: Hardware Keyboard: macOS engine#23469
• Fuchsia: (Not within scope for now)
• Codegen: Hardware keyboard: codegen #73440
• Flip the switch
• Migrate

Ask for recheck afterwards:

• [macOS] occasionally Shift keyPressed throws failed assertion exception #74138

[edwardaux]

Hating to be one of "those guys", but I'm curious if this ticket is still being actively pursued?

There's a bunch of other tickets that are being closed in favour of this one... but if this ticket isn't being worked on (or if the anticipated completion date is still months/years away), then there's a bit of a gap where genuine keyboard problems are impacting users in the meantime.

Not trying to be difficult... just trying to see how aggressively I should be pursuing workarounds to my existing keyboard problems vs. waiting for a fix.

[dkwingsmt]

@edwardaux Yes I'm still fully focusing on the keyboard system, especially all the issues that were found recently.

[edwardaux]

Ah, lovely. Thanks for the status update @dkwingsmt ... I appreciate that it is a big task 👍

[flutter-triage-bot]

This issue is assigned to @dkwingsmt but has had no recent status updates. Please consider unassigning this issue if it is not going to be addressed in the near future. This allows people to have a clearer picture of what work is actually planned. Thanks!

[flutter-triage-bot]

This issue was assigned to @dkwingsmt but has had no status updates in a long time. To remove any ambiguity about whether the issue is being worked on, the assignee was removed.

[dkwingsmt]

@gspencergoog has gone through the trouble of migrating everything in the Framework to KeyEvent and onKeyEvent and started a deprecation. Let's call this issue done!

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.