This fixes a problem in Android key event handling where, because I was only using a single bool to indicate that we were re-dispatching, there was a race condition when multiple keys were pending (sent to the framework, awaiting responses).
This fixes that by switching to a mechanism that uses the event itself to tell if it was redispatched.
In doing this, I realized that because key events can come from either the dispatchEvent call, or through the InputConnectionAdaptor, I needed to handle both routes properly so that the events would all be handled, and all go through the same mechanism on the framework side.
This (mostly) re-lands #21163, which was reverted in #22321
This switches from using onKeyDown to using dispatchKeyEvent on Android so that keys can be intercepted handled by the framework and not continue to be dispatched to other controls.
It also now intercepts key events sent to InputConnection.sendKeyEvent, as some IMEs do (e.g. the Hacker's Keyboard), and sends them to Flutter.
This fixes the problem where (for example) pressing TAB on a hardware keyboard sends the tab to both the text field and to the focus traversal system.
Note that we still can't intercept all keystrokes given to a soft keyboard, only those which the soft keyboard decides to send to InputConnection.sendKeyEvent, and system keys (like the back button) are only received if the IME doesn't eat them.
This re-lands #21163, which was reverted in #22004
Now that flutter/flutter#67359 has landed, this change will no longer cause spaces (and other shortcuts) to be ignored in text fields if there is no action associated with the intent, even if there is a shortcut key mapping to an intent.
It also no longer causes web test failures (as far as I can tell without submitting it: the same tests don't fail locally).
Here's the original PR description:
This switches from using dispatchKeyEvent to using dispatchKeyEventPreIme so that keys can be intercepted before they reach the IME and be handled by the framework.
It also now intercepts key events sent to InputConnection.sendKeyEvent, as some IMEs do (e.g. the Hacker's Keyboard), and sends the to Flutter before sending them to the IME (which it now only does if they are not handled by the framework).
This fixes the problem where pressing TAB on a hardware keyboard sends the tab to both the text field and to the focus traversal system.
Note that we still can't intercept all keystrokes given to a soft keyboard, only those which the soft keyboard decides to send to InputConnection.sendKeyEvent.
This re-lands #20496 and #21780 after fixing the semantics-enabling code that was causing the post-submit web_smoke_test to fail.
Below is the description from the original PR:
This is a PR for converting the dart:ui code in the engine to use a multi-window API. The goal here is to convert from the window singleton to an API that has the concept of multiple windows. Also, I'm matching up the new PlatformDispatcher class to talk directly to the PlatformConfiguration class in the engine. I'm not attempting to actually enable creating multiple windows here, just migrate to an API that has a concept of multiple windows. The multi-window API in this PR currently only ever creates one window.
The design doc for this change is here.
The major changes in this PR:
Move the platfom-specific attributes out of Window, and into the new PlatformDispatcher class that holds all of the platform state, so that the platform code need only update the configuration on this class.
Create FlutterView, FlutterWindow, and SingletonFlutterWindow classes to separate out the concepts of a view (of which there may be multiple in a window), a window (of which there may be multiple on a screen, and they host views), and a window where there is only ever expected to be one (this hosts the entire API of the former Window class, and will eventually be the type of the window singleton).
Next step after this PR lands:
Remove the Window class entirely (it is replaced by SingletonFlutterWindow). Some minor changes in the Framework are needed to switch to using SingletonFlutterWindow directly first.
The Window class still exists in this PR, but will be removed as soon as the framework is converted to point to the SingletonFlutterWindow class instead. They share the same API, just have different names (Window is currently a subclass of SingletonFlutterWindow). The intention is that the Window name will be freed up to use as a widget class name in the framework for managing windows. The singleton called window will remain, and keep the same API it has now.
This re-lands #21163, which was reverted in #21513
Now that flutter/flutter#67359 has landed, this change will no longer cause spaces (and other shortcuts) to be ignored in text fields if there is no action associated with the intent, even if there is a shortcut key mapping to an intent.
Here's the original PR description:
This switches from using dispatchKeyEvent to using dispatchKeyEventPreIme so that keys can be intercepted before they reach the IME and be handled by the framework.
It also now intercepts key events sent to InputConnection.sendKeyEvent, as some IMEs do (e.g. the Hacker's Keyboard), and sends the to Flutter before sending them to the IME (which it now only does if they are not handled by the framework).
This fixes the problem where pressing TAB on a hardware keyboard sends the tab to both the text field and to the focus traversal system.
Note that we still can't intercept all keystrokes given to a soft keyboard, only those which the soft keyboard decides to send to InputConnection.sendKeyEvent.
* Revert "Fix documentation build for window changes. (#21780)"
This reverts commit 931a04683d6eb49fc92059b2384ac5b1618d5422.
* Revert "Migration to PlatformDispatcher and multi-window (#20496)"
This reverts commit 85b0031f73544e448354047dc6a236c0b0808252.
This is a PR for converting the dart:ui code in the engine to use a multi-window API. The goal here is to convert from the window singleton to an API that has the concept of multiple windows. Also, I'm matching up the new PlatformDispatcher class to talk directly to the PlatformConfiguration class in the engine. I'm not attempting to actually enable creating multiple windows here, just migrate to an API that has a concept of multiple windows. The multi-window API in this PR currently only ever creates one window.
The design doc for this change is here.
The major changes in this PR:
Move the platfom-specific attributes out of Window, and into the new PlatformDispatcher class that holds all of the platform state, so that the platform code need only update the configuration on this class.
Create FlutterView, FlutterWindow, and SingletonFlutterWindow classes to separate out the concepts of a view (of which there may be multiple in a window), a window (of which there may be multiple on a screen, and they host views), and a window where there is only ever expected to be one (this hosts the entire API of the former Window class, and will eventually be the type of the window singleton).
Next step after this PR lands:
Remove the Window class entirely (it is replaced by SingletonFlutterWindow). Some minor changes in the Framework are needed to switch to using SingletonFlutterWindow directly first.
The Window class still exists in this PR, but will be removed as soon as the framework is converted to point to the SingletonFlutterWindow class instead. They share the same API, just have different names (Window is currently a subclass of SingletonFlutterWindow). The intention is that the Window name will be freed up to use as a widget class name in the framework for managing windows. The singleton called window will remain, and keep the same API it has now.
This switches from using dispatchKeyEvent to using dispatchKeyEventPreIme so that keys can be intercepted before they reach the IME and be handled by the framework.
It also now intercepts key events sent to InputConnection.sendKeyEvent, as some IMEs do (e.g. the Hacker's Keyboard), and sends the to Flutter before sending them to the IME (which it now only does if they are not handled by the framework).
This fixes the problem where pressing TAB on a hardware keyboard sends the tab to both the text field and to the focus traversal system.
Note that we still can't intercept all keystrokes given to a soft keyboard, only those which the soft keyboard decides to send to InputConnection.sendKeyEvent.
This re-lands the key event synthesis implementation for Android (Original PR: #19024, Revert PR: #19956). The only difference is sending the synthesized key events to the root view instead of the current view.
Without sending it to the root view, the system doesn't have any chance of handling keys like the back button. The event will still not be sent to the framework twice, since we turn off event propagation while re-dispatching the event.
