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
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.
This implements the Gtk hooks required to support multi-step input
methods on Linux. This builds on the support for composing regions
(preedit region in Gtk terminology) added to TextInputModel in
https://github.com/flutter/engine/pull/21682.
Specifically, the following changes are included:
1. Add handler for TextInput.setMarkedTextRegion framework messages: On
any change to the EditableText in the framework, this message is sent
which provides an updated rect (in the local co-ordinates of the
EditableText) for the composing region. If not in composing mode, the
cursor rect is sent.
2. Add handler for TextInput.setEditableSizeAndTransform framework messages:
On any change to the RenderObject underlying the EditableText, an
updated size for the full EditableText widget, as well as an affine
transform matrix from local co-ordinates to Flutter root co-ordinates is
sent.
3. On either of the above messages, we use the transformed composing
rect to compute the cursor position in Gtk window co-ordinates and
inform Gtk, so that it can position any system IM composing window
correctly for on-the-spot composing, such as is used when inputting
Japanese text.
4. Adds handlers for preedit-start, preedit-changed, and preedit-end
signals from Gtk. These are passed on to the TextInputModel.
5. Updates the preedit-commit handler to commit the composing region to
the text or, if not composing, insert new text at the cursor.
6. Updates the handler for TextInput.setEditingState framework messages
to extract the composing range base and extent and pass these on to
TextInputModel.
7. Updates update_editing_state function to set composing base and
extent on text input state updates sent to the framework.
This PR fixes a few small memory leaks in FlTextInputPlugin. All three cases
are creating temporary FlValue instances for lookups and comparison without
ever releasing them.
In an upcoming patch, we'll enable enforcement that all FLUTTER_NOLINT
comments include an issue link. This migrates the remaining uses to that
format.
Bug: https://github.com/flutter/flutter/issues/68273
