A ticket showing how browsers mispasses the Tab key event to Facebook when shouldn't.

[ShikiSuen]

[macOS] Please stop websites handling Tab key events if it is already handled by an input method.

Chrome version: 109.0.5414.87
Edge-Chromium version: 109.0.1518.52
Safari version: 18614.3.7.1.5 (running 259258@main through Terminal.)

Steps:

1. Install either vChewing (at least 3.3.1) or McBopomofo (at least 2.4.2) on macOS (at least 10.13).
2. Loggin to Facebook, use any of the input methods mentioned above to start typing something in a post editor, supposing that you are writing a new post.
3. Press (Shift+)Tab key to rotate between candidates.

Description:

• The problem doesn't happen in FireFox.

By pressing the Tab key when the composition-buffer (whether inline or not, i.e. pre-edit area) is not empty, vChewing and McBopomofo rotates between candidates.

// vChewing shows the current candidate index (as a little popup tooltip) when rotating candidates.
// vChewing also supports inline candidate rotation with Option+Up/Down (or Option+Left/Right when vertical typing), mitigating the issue reported by this thread.

However, in the scenario mentioned in the "Steps to reproduce problem", both Chrome and Safari handles the Tab key even if it is "handled and returned true" by the input method.

It worths mentioning that any NSEvent handled and returned-true by an input method is not expected to be handled again by the client app. Both Safari and Chrome dismissed that.

(I'll file a separate bug report to Safari bugzilla.)

Screenshot (video):

This video demonstrates this issue using FireFox, Edge-Chromium and Chrome, indicating that FireFox doesn't have this issue.

FacebookTabKey.mp4

The following video demonstrate how Safari bugs with this (with different behavior):

FacebookTabKey-Safari.mp4

[ShikiSuen]

https://bugs.chromium.org/p/chromium/issues/detail?id=1409762
https://bugs.webkit.org/show_bug.cgi?id=251061