This changes the Windows text handling so that keyboard events are sent to the framework first for handling, and then passed to the text input plugin, so that the framework has a chance to handle keys before they get given to the text field.
This is complicated by the async nature of the interaction with the framework, since Windows wants a synchronous response. So, in this change, I always tell Windows that the event was handled, and if the framework (eventually) responds that it wasn't, then I synthesize a new event and send it with SendEvent.
I also added support for detecting "extended" keys, since that was missing, and converted the OnKey handlers in the API to return a bool to indicate whether or not they have handled the event.
During multi-step text input composing, such as with Chinese, Japanese,
and Korean text input, the framework sends embedders cursor rect updates
in the form of two messages:
* TextInput.setMarkedTextRect: notifies the embedder the size and
position of the composing text rect (or cursor when not composing) in
local coordinates.
* TextInput.setEditableSizeAndTransform: notifies the embedder of the
size of the EditableText and 4x4 transform matrix from local to
PipelineOwner.rootNode coordinates.
On receipt of either message, we cache a local copy on the
TextInputPlugin and notify the Win32FlutterWindow of the updated cursor
rect. In a followup patch, we update Win32FlutterWindow to implement the
Win32 input manager (IMM) calls required to position the IME candidates
window while editing.
This change removes workarounds that were introduced prior to landing
Dart language feature
https://github.com/dart-lang/language/issues/1274, which allows type
promotion in null safe code to account for local boolean variables.
The workarounds ensured that the code would analyze the same
regardless of whether the feature was enabled, allowing for a smoother
transition. Now that the feature has fully landed, the workarounds
aren't needed anymore.
This is a partial revert of 1181890b8e94c8cc72928df526f49dcc6ce7cdb2
On some devices we still need to the original search paths approach
because dlopen with just the base file name doesn't work. We're
combining both approaches now, adding the base filename as the first
entry in the searchPaths.
When .so files are in the lib/ path in the APK, it can be dlopen-ed
directly using just the filename. We don't need to search for the file.
The interface has thus been changed to accept a single path instead of a
search directory.
Also instead of hardcoding the .so basename and assets directory, read
them from FlutterApplicationInfo instead.
* Revert "Revert "[CanvasKit] Automatically fall back to Noto fonts (#23096)" (#23357)"
This reverts commit b00fa0f20a358c2e78d54a0c7d2e5c93c4234880.
* WIP
* Use an Interval Tree to store the unicode ranges for the Noto Fonts
* Update licenses
* Remove debug print statements
* Respond to comments
* Fix analysis error
* Add tests
* Respond to comments
* Fix test
* Update goldens lock
* Skip screenshot test on Safari
* Skip CanvasKit tests on iOS Safari
* Move CanvasKit initialization so it doesn't run on iOS Safari
