This PR changes the format check on CI to use the command added in
https://github.com/flutter/engine/pull/50747.
Additionally, while making this change, I noticed that the CI check was
not checking the formatting of all files, and that as a result, files
were present in the repo with incorrect formatting. I have fixed the
formatting and fixed the check to always check all files.
The existing code worked, but it cleared the objects before calling
init_keyboard. This made it look like init_keyboard might leak the
existing values. If a third case was added later where init_keyboard was
called it would leak if the caller didn't clear the objects before
calling it.
Generated by https://github.com/flutter/engine/pull/48903 (`dart ./tools/header_guard_check/bin/main.dart --fix`).
As discussed with @cbracken and @jmagman, the guards are not technically needed on the Mac/iOS code, but they (a) do not hurt and (b) still provide value if for some reason `#include` is used instead of `#import` (though I suspect we could try to add that to the tool in the future as well).
Reverts flutter/engine#48849
Initiated by: loic-sharma
This change reverts the following previous change:
Original Description:
This migrates the Windows embedder to `FlutterCompositor` so that the engine renders off-screen to a framebuffer instead of directly onto the window's surface. This will allow us to support platform views and multiple views on Windows.
<details>
<summary>Tests...</summary>
* Verify OpenGL compositor's raster time isn't regressed and memory increase is reasonable
* Software compositor's raster time and memory isn't regressed
Test device configurations
* [x] Windows 11 (hardware acceleration enabled/disabled)
* [x] Windows Arm64 (hardware acceleration enabled/disabled)
* [x] Windows 7 (hardware acceleration enabled/disabled, DWM enabled/disabled)
</details>
Addresses https://github.com/flutter/flutter/issues/128904
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
This migrates the Windows embedder to `FlutterCompositor` so that the engine renders off-screen to a framebuffer instead of directly onto the window's surface. This will allow us to support platform views and multiple views on Windows.
<details>
<summary>Tests...</summary>
* Verify OpenGL compositor's raster time isn't regressed and memory increase is reasonable
* Software compositor's raster time and memory isn't regressed
Test device configurations
* [x] Windows 11 (hardware acceleration enabled/disabled)
* [x] Windows Arm64 (hardware acceleration enabled/disabled)
* [x] Windows 7 (hardware acceleration enabled/disabled, DWM enabled/disabled)
</details>
Addresses https://github.com/flutter/flutter/issues/128904
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
GtkApplication windows contain a reference back to the application. This
means the MyApplication object in the Flutter application never
disposes. We workaround this by removing these references before we
quit. This occurs for all GTK applications that quit using this method,
see https://gitlab.gnome.org/GNOME/gtk/-/issues/6190. This may be fixed
upstream at some point but the proposed workaround should solve the
problem for all versions and not conflict with any upstream solution.
Fixes https://github.com/flutter/flutter/issues/136582
## Description
This moves the state update to only happen on realizing the window instead of at initialization time, based on [the comment from](https://github.com/flutter/flutter/issues/137262#issuecomment-1792020246) @robert-ancell .
## Related Issues
- https://github.com/flutter/flutter/issues/137262
## Tests
- I tried to add tests, but it doesn't seem possible to create a view without an actual display connected (and making a mock of it defeats the purpose of the test). I'm happy to be proven wrong, though.
As part of eliminating the Flutter buildroot
(https://github.com/flutter/flutter/issues/67373), we are moving all
third-party dependencies from //third_party to //flutter/third_party.
Once all third-party dependencies have been migrated, tooling and config
will be moved and the buildroot will be eliminated altogether.
No tests changed because there is no semantic change to this PR. This is
simply relocating a dependency.
## Description
This PR fixes a mistake I made on https://github.com/flutter/engine/pull/44636 where the error handling code wrongly relied on `fl_method_channel_invoke_method_finish` instead of `fl_binary_messenger_send_on_channel_finish`.
The error handling code was not called when running the tests added in https://github.com/flutter/engine/pull/44636 so this mistake did not pop up.
@robert-ancell I added a test that simulates an error response and I had to rely on `g_idle_add` to make it works. Is this approach ok?
## Related Issue
Linux implementation for https://github.com/flutter/flutter/issues/132386
## Tests
Adds one test.
As noticed in 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.
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.
## 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 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
## Description
This reverts commit 879917b to re-land #40542 to fix the lint warning which caused the original PR to be reverted (the lint warnings were turned on after the original was landed, which is why it wasn't caught earlier).
