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.
Switches the Linux embedding from the standard C API to the new proctable version, to allow for unit testing of the embedding layer separately from the embedder APIs implementation.
Currently, the Linux embedder does not handle window exposure events.
This is typically not a problem for users who use compositing window
managers, since they keep the display buffers even if the window is
completely covered. However, for users that don't use a compositor, the
window will not be redrawn by the engine if it was previously covered
until another event triggers the redraw.
This patch implements the GtkWidget draw callback to handle window
exposure events. The callback doesn't actually draw anything, it just
schedule a frame for drawing by the engine.
The engine doesn't support exposure events, so instead, we force redraw
by sending a window metrics event of the same geometry. Since the
geometry didn't change, only a frame will be scheduled.
Switches the Windows embedding from the standard C API to the new proctable version, to allow for unit testing of the embedding layer separately from the embedder APIs implementation. This includes moving some engine messaging that was still in flutter_windows to the C++ engine class to better encapsulate the proc table.
Converts the macOS embedding to use the new proc table version of the embedding API, and adds one example unit test using it to demonstrate and validate the approach.
The framework handles arrow keys, delete, and backspace (and with better
unicode support), so we shouldn't handle them at the embedding level.
Fixes#69202
Fix incorrect parameter used for self object
Rename the GWeakNotify function parameters.
This matches the prototype and makes it harder to accidentally use the object
parameter the wrong way.
The Flutter framework now has handling for arrow keys and backspace
in its editable text, so they no longer need to be handled in the
embedding. This not only avoids duplicate work, but improves the
handling of complex unicode (surrogate pairs, grapheme clusters) which
are currently correctly handled in the framework but not the macOS
embedding.
Fixes https://github.com/flutter/flutter/issues/68497
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.
* Reland fuchsia external view embedder will be shared with platform view
This reverts commit 9b752790f4d25ab238576c719208d7a38c6293f3.
* wait for the external view embedder to be initialized before creating
shell
This regression was introduced in https://github.com/flutter/engine/pull/21820
for sound-null safety. The settings used to launch the VM were incorrectly used
to determine the isolate lifecycle callbacks. Since the first shell/engine in
the process also starts the VM, these objects are usually identical. However,
for subsequent engine shell/engine launches, the callbacks attached to the new
settings object would be ignored. The unit-test harness is also structured in
such a way that each test case tears down the VM before the next. So all
existing tests created a bespoke VM for the test run, and, the tests that did
create multiple isolates did not also test attaching callbacks to the settings
object.
Fixes https://github.com/flutter/engine/pull/22041
Embedders that have access to the Dart native API (only Fuchsia now) may perform
library setup in the isolate create callback. The engine used to depend on the
fact the root isolate entrypoint is invoked in the next iteration of message
loop (via the `_startIsolate` trampoline in `isolate_patch.dart`) to ensure that
library setup occur before the main entrypoint was invoked. However, due to
differences in the way in which message loops are setup in Fuchsia, this
entrypoint was run before the callback could be executed. Dart code on Fuchsia
also has the ability to access the underlying event loops directly. This patch
moves the invocation of the create callback to before user dart code has a
chance to run. This difference in behavior on Fuchsia became an issue when the
isolate initialization was reworked in https://github.com/flutter/engine/pull/21820
for null-safety.
Another issue was discovered in that the callback was being invoked twice, I
fixed that too and added a test.
Fixes https://github.com/flutter/flutter/issues/68732
