Changes required for this roll:
* addition of LLVM libc (which is now a dependency of libcxx)
* updates the to license script
* patching the verify_exported check to allow some symbols added by
libcxx
* annotations for clang-tidy warnings
fixes#112207
## What's new?
- Added a `view_id` on `UpdateSemantics`
- Added a `view_id` on `DispatchSemanticsAction`
- Piped the `view_id` all over creation
- Updated tests for these actions across the different platforms
- Added `FlutterEngineSendSemanticsAction` to the embedder API in order
to not break `FlutterEngineDispatchSemanticsAction`
- Using this view ID properly on the Windows platform (see
`engine/src/flutter/shell/platform/windows/flutter_windows_engine.cc`)
## How to test
1. Checkout
[foundation-plus-framework](https://github.com/canonical/flutter/pull/36)
from canonical/flutter
2. Merge this branch into it
3. Enable the "Narrator" screen reader on windows
4. Run the Multi window reference app (see
[PR](https://github.com/canonical/flutter/pull/36) for details)
5. Open up another window, and note that the right buttons and things
are being highlighted, as the screenreader would expect 🎉
## Pre-launch Checklist
- [x] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [x] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [x] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.
For views created with fl_view_new_for_engine() the cursor processing
was subscribed to before the window had realized. This caused the
following warnings on startup:
[+3105 ms] (com.example.flutter_multi_view_test:619234): Gdk-CRITICAL
**: 13:00:35.501: gdk_window_get_display: assertion 'GDK_IS_WINDOW
(window)' failed
[ ] (com.example.flutter_multi_view_test:619234): Gdk-CRITICAL **:
13:00:35.501: gdk_cursor_new_from_name: assertion 'GDK_IS_DISPLAY
(display)' failed
[ ] (com.example.flutter_multi_view_test:619234): Gdk-CRITICAL **:
13:00:35.501: gdk_window_set_cursor: assertion 'GDK_IS_WINDOW (window)'
failed
Co-authored-by: Matthew Kosarek <matt.kosarek@canonical.com>
The previous code was built where there was only one view, and this view
provided the callback to the engine.
Now we have multiple views, they all should process the semantics update
and so the callback is replaced with a signal. This is similar to the
signal used for engine restarts.
---------
Co-authored-by: Harlen Batagelo <hbatagelo@gmail.com>
This was previously connected to right alt, which was confusing the
keyboard handling code into generating up events for this key when it
didn't match the expected values. This key is also configurable, and
only defaults to right alt in Ubuntu/GNOME.
Fixes https://github.com/flutter/flutter/issues/154053
Create the display monitor at initialization, not engine start.
Handle case where the window is not visible and the monitor can't be
determined.
Don't leak the monitor when the engine is disposed.
There can only be one handler that is shared between the views.
Move event redispatch matcher back into FlKeyboardManager - if a
redispatched event was moved between views due to a focus change it
would not be matched against.
Instead of doing the redispatching from inside FlKeyboardManager, return
the event asynchronously to the code that provided the event in the
first case. That code has all the context on how to do the redispatch -
this will be more complicated in a multi-view case.
Remove pending keyboard event ID and use the object directly.
Use references to make sure FlKeyboardManagerData is freed.
Refactor marking events as handled
Split the channel messaging out of the system channels to make them
simpler to understand and refactor.
The new channel classes could be automatically generated in a second
phase, e.g. using Pigeon to reduce code usage.
The new classes don't have tests as they will already be covered by the
existing code.
The previous mock required knowing the specific functions used in the
binary messenger, this method instead allows test code to provide
complete platform channel implementation for testing and make simulated
platform channel calls into embedder code.
Incorrect reference counting of GTask objects meant platform channel
method calls would leave tasks alive that would leak memory and leave
unclosed references to the binary messenger.
The same problem with NVIDIA drivers which causes issue [152099](https://github.com/flutter/flutter/issues/152099) occurs with Vivante Corporation drivers.
Quick fix for issue on Vivante drivers:
https://github.com/flutter/flutter/issues/152099
- [ x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
- [ x] I read the [Tree Hygiene] wiki page, which explains my responsibilities.
- [ x] I read and followed the [Flutter Style Guide] and the [C++, Objective-C, Java style guides].
- [ x] I listed at least one issue that this PR fixes in the description above.
- [ x] I added new tests to check the change I am making or feature I am adding, or the PR is [test-exempt]. See [testing the engine] for instructions on writing and running engine tests.
- [ x] I updated/added relevant documentation (doc comments with `///`).
- [ x] I signed the [CLA].
- [ x] All existing and new tests are passing.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Split the channel messaging out of the system channels to make them
simpler to understand and refactor.
The new channel classes could be automatically generated in a second
phase, e.g. using Pigeon to reduce code usage.
The new classes don't have tests as they will already be covered by the
existing code.
