We'd like to (or already are) using the concurrent message loop for high priority rendering tasks like PSO construction and render pass encoding. The default priority level for the engine managed concurrent message loop is 2, which is a significantly lower priority than the raster thread at -5. This is almost certainly causing priority inversion.
We must move back to dedicated runners so we can adjust thread priorities.
https://github.com/flutter/flutter/issues/126209
## 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] 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 Hixie said 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.
Make Robolectric tests work with SDK 33. The Robolectric doesn't support create presentation window now, so this CL also adds a custom presentation shadow to hook showing state to make related tests work.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Fixes https://github.com/flutter/flutter/issues/128746
Prints a warning the first time a platform channel sends a message from the wrong thread with instructions/link to the site about how to fix this.
## Description
This PR changes how a null message is handled by the Linux engine for a basic message channel.
**Before**:
- when receiving a null message a warning was emitted.
- `fl_binary_messenger_send_response` was called but failed and the application exited.
```
** (bug:9866): WARNING **: 23:13:42.109: Failed to decode message: Unexpected end of data
** (bug:9866): CRITICAL **: 23:13:42.109: gboolean send_response(FlBinaryMessenger *, FlBinaryMessengerResponseHandle *, GBytes *, GError **): assertion 'response_handle->response_handle != nullptr' failed
```
**After**:
- Receiving a null message is handled as expected from the framework side documentation:
9287e81d52/packages/flutter/lib/src/services/platform_channel.dart (L149-L150)
## Related Issue
Fixes https://github.com/flutter/flutter/issues/128704
## Tests
Adds 2 tests.
Fixes https://github.com/flutter/flutter/issues/118761.
For some context: ImeSyncDeferringInsetsCallback extends [WindowInsetsAnimation.Callback](https://developer.android.com/reference/android/view/WindowInsetsAnimation.Callback) specifically to handle insets related to keyboard animations.
When a keyboard animation happens, we get a call to onPrepare with the animation, and then to onApplyWindowInsets with [WindowInsets](https://developer.android.com/reference/android/view/WindowInsets) that represent the post animation state. For example, for hiding the keyboard, we would get WindowInsets with height of 0 for insets of type WindowInsets.Type.ime() (input method editor). We save these post-animation insets.
We then get calls to onProgress for each frame of the animation, and use the WindowInsets passed to onProgress to build new WindowInsets based on the saved post-animation insets, but with the keyboard insets overridden by the WindowInsets passed to onProgress.
Finally, we get a call to onEnd, where we apply the saved insets.
However, there can be multiple animation running at the same time. For example, dismissing the keyboard can result in an animation associated solely with the keyboard happening, as well as an animation associated only with the navigation bar happening. And they can start at slightly different times. This can result in the situation described in this comment: https://github.com/flutter/flutter/issues/118761#issuecomment-1574284505
Re-setting needsSave to false ensures we don't ignore any updates to the final state, ensuring correct insets in onProgress and onEnd.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
This PR gives an overview of how floating cursor feature works (including the new floating cursor selection gesture, and the existing floating cursor move gesture). It can serve as the missing design doc.
I put it in the engine rather than the framework, since all logics are in one place, and it's closer to the UIKit behavior that I want to cover.
Thanks @moffatman for helping me understanding it.
*List which issues are fixed by this PR. You must list at least one issue.*
https://github.com/flutter/flutter/issues/30476
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
The `isRTLAtPosition` method had a bug, it used `NSInteger max = [_selectionRects count]` instead of `NSInteger max = [_selectionRects count] - 1`. But I realized we don't even need the function any more, it was used in a few places in previous iterations of #36643, but in the only place remaining, we actually already have the selection rect and don't need to search for it by position.
Btw as an explanation of the crash, I guess there is some mismatch between code point and character count somewhere. UIKit was asking for `caretRectForPosition:2` when we only had 1 character. This could have only crashed when floating cursor selection was used, but actually when switching to CJK keyboard, UIKit turns out to use `caretRectForPosition` to calculate something about the composing rect.
Fixes https://github.com/flutter/flutter/issues/128031
Fixes a few issues with the Linux text editing delta implementation that was causing some issues when composing CJK text.
`im_preedit_changed_cb` dispatches a delta with the delta range set as the current composing region causing a crash when composing because the new composing region range might not yet exist in the `oldText` that the delta is applied to. We should instead send the composing region before the change to the text as that will be the correct range that is being modified in the `oldText`.
`im_preedit_end_cb` dispatches a delta with an empty `oldText`, a not empty `deltaText`, and a delta range of `(-1,-1)` causing a crash when composing ends because the delta range will never be within the range of the text. We should instead send the current text value as the `oldText` and not send a `deltaRange` or `deltaText` since a `(-1,-1)` range essentially means nothing in the text changed.
`im_commit_cb` does not account for the case when we were previously composing when the text was committed. This causes the dispatched delta to have a delta range that always inserts at the current the selection, when it should instead replace the previous composing range. We should account for the case when we are previously composing before committing the text, and dispatch a delta with the previous composing region.
Fixes https://github.com/flutter/flutter/issues/113909
Sometimes the time point created late will less than the time point create earlier since the CLOCK SOURCE has changed.
We must make sure the CLOCK SOURCE (fml::TimePoint) is always keep the same while we are testing.
Corrects the test case is needed before we fix the problem completely.
## Description
This PR fixes an issue related to text input plugin, on IOS, sending a wrong action string to the engine for `FlutterTextInputActionContinue`.
## Related Issue
Fixes https://github.com/flutter/flutter/issues/126922
## Tests
Adds 1 test.
Previously, when creating native platform views on macOS, we ignored any parameters passed via the framework side "params" argument in the "create" method call, and instead always passed a nil value to the FlutterPlatformViewFactory. This made it impossible for users of macOS platform views to pass constructor arguments to the NSView subclass implementing the platform view.
We now decode the arguments data using the codec specified by the `FlutterPlatformViewFactory` and pass them through to the `[FlutterPlatformViewFactory createWithIdentifier:arguments:]` method where the platform view author can make use of them.
Fixes: https://github.com/flutter/flutter/issues/124723
This is a part of the broader macOS platform view support effort: https://github.com/flutter/flutter/issues/41722
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Normally when platform view is clipped to a simple rect we rely on
clipping to container layer bounds. However when the clip rect is
rotated the container layer is expanded accordingly and clipping to path
must be used instead.
Fixes https://github.com/flutter/flutter/issues/128175
For consistency with Flutter (and all other platforms), Flutter views in the macOS embedder set `isFlipped` to ensure a co-ordinate system with the origin in the top-left, with y co-ordinates increasing towards the bottom edge of the view.
Previously, we were using a stock NSView as the container, which uses a bottom-left origin by default. Instead we extract the PlatformView container view as its own class with `isFlipped` true.
This doesn't correct the issue of the view anchorpoint/position but does correct rotation direction.
This also applies the transform back to origin prior to other transforms when adjusting the platformview position rather than after.
Issue: https://github.com/flutter/flutter/issues/124490
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
