Fixes https://github.com/flutter/flutter/issues/142488
- Only logs on iOS if Skia is used instead of Impeller.
- Logs on other platforms if Impeller is used instead of Skia.
- Uses "IMPORTANT" rather than "ERROR" for these logs. This will show up by default since flutter_tools sets ERROR and above as logs to show.
- Adds some tests.
- Makes INFO log print file paths the same as other verbosities.
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).
Fixes https://github.com/flutter/flutter/issues/141571
Shell::Screenshot was impelemnted in a Skia-only way and would crash when invoked. Adds test coverage for the breaking path on iOS that ends up calling `FlutterView drawLayer`.
The AppKit state machine was not well understood before. Sometimes the engine would leave orphan PanZoomStart after a certain sequences including NSEventPhaseMayBegin
Now track each gesture's specific phase instead of boolean true/false which doesn't really accurately represent the system state.
Fixes https://github.com/flutter/flutter/issues/140730
FIxes https://github.com/flutter/flutter/issues/136622
We are embedding Flutter into MacOS app, and noticed that there is a
leak. `leaks` tool says there is a cycle reference:
```
12 (2.11K) ROOT CYCLE: <FlutterKeyboardManager 0x29ec55f40> [80]
8 (432 bytes) __strong _primaryResponders --> ROOT CYCLE: <NSMutableArray 0x29ec560a0> [64]
7 (368 bytes) ROOT CYCLE: <NSMutableArray (Storage) 0x29ec56140> [32]
4 (224 bytes) ROOT CYCLE: <FlutterEmbedderKeyResponder 0x29ec56310> [80]
1 (48 bytes) __strong _sendEvent --> ROOT CYCLE: <__NSMallocBlock__ 0x29ec56360> [48]
__strong [capture] --> CYCLE BACK TO <FlutterKeyboardManager 0x29ec55f40> [80]
1 (48 bytes) __strong _pendingResponses --> <NSMutableDictionary 0x29ec563c0> [48]
1 (48 bytes) __strong _pressingRecords --> <NSMutableDictionary 0x29ec56390> [48]
2 (112 bytes) <FlutterChannelKeyResponder 0x29ec56450> [48]
1 (64 bytes) __strong _channel --> <FlutterBasicMessageChannel 0x29ec564e0> [64]
2 (1.55K) __strong _layoutMap --> <NSMutableDictionary 0x29ec56630> [48]
1 (1.50K) <NSMutableDictionary (Storage) 0x123c34a00> [1536]
1 (64 bytes) __strong _pendingEvents --> <NSMutableArray 0x29ec565f0> [64]
```
This patch uses `weak` pointer to `self` instead of implicit `strong`.
## 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 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.
We're on a version of clang that crashes a lot on macOS. This PR rolls
clang forward to a new release from the Fuchsia toolchain team. If it
does not fix the crash, we can roll back with
https://github.com/flutter/engine/pull/49249. Both rolling forward and
back require the fixes to the `.mm` file in this PR.
This PR implements `FlutterMetalLayer`, a drop-in (as far as Flutter is
concerned) replacement for `CAMetalLayer`. The biggest difference is
that `FlutterMetalLayer` can present frames from background thread
within a `CATransaction`.
`FlutterMetalLayer` is disabled by default. To opt-in, add the following
item to `Info.plist`:
```xml
<key>FLTUseFlutterMetalLayer</key>
<true/>
```
The performance seems quite good, consistent 120hz on iPhone 13 Pro.
Benefits
- presenting with transaction from background thread, which, down the
line, would allow for platform views without thread merging.
- fine control over how the surface is displayed - we can display single
surface on multiple `CALayers`, each showing different part, allowing
for performant implementation of unobstructed platform views.
Drawbacks
- this not being a metal layer makes working with metal instrument tools
more awkward
Create a `PrivacyInfo.xcprivacy` (this name is required) plist and move it to the top-level of the iOS framework bundle. `NSPrivacyTracking*` and `NSPrivacyCollectedDataTypes` keys are required, but the values are blank.
Apple [now requires](https://developer.apple.com/documentation/bundleresources/privacy_manifest_files) that third-party frameworks must include this manifest to document usage of particular APIs and [how they are used](https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api).
> Starting in fall 2023, when you upload a new app or app update to App Store Connect that uses an API (including from third-party SDKs) that requires a reason, youâll receive a notice if you havenât provided an approved reason in your appâs privacy manifest. And starting in spring 2024, in order to upload your new app or app update to App Store Connect, youâll be required to include an approved reason in the appâs privacy manifest which accurately reflects how your app uses the API.
https://developer.apple.com/news/?id=z6fu1dcu
@stuartmorgan [audited](https://github.com/flutter/flutter/issues/131494#issuecomment-1852718759) the engine and third_party:
> * File timestamps:
>
> * `C617.1` for app state restoration in `FlutterAppDelegate.mm`.
> * `0A2A.1` for implementation of the relevant `File` wrappers.
> * System boot time:
>
> * `35F9.1` for various event timing and elapsed time calculations.
Note macOS frameworks do not need to declare `NSPrivacyAccessedAPITypes`.
I don't think this will require recipe or conductor codesign changes since this is a file copied as a resource into the framework, just as the modulemap and Info.plist aren't referenced anywhere.
I'm not quite sure how to test this other than letting it build and generate a `Generate Privacy Report` in a Flutter app in Xcode. There's no where we check that, say, the Info.plist is copied to the right place in Flutter.framework (even in flutter/flutter). When this rolls into the framework I will add a check to [ios_content_validation_test.dart](3da9bc1698/dev/devicelab/bin/tasks/ios_content_validation_test.dart)
On this PR the `PrivacyInfo.xcprivacy` was written to the expected location in the Flutter.framework:
d45cd08094/516/tree
Fixes https://github.com/flutter/flutter/issues/131494
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
I was shocked this was even legal earlier. But a new Clang roll makes this an a warning which gets converted into an error.
I attempted to roll to the Clang roll the roller did and fixed the issues I found. Hopefully, the next roll is unblocked.
Original failure: https://github.com/flutter/engine/pull/48563
This PR adds multiview support for `ExternalViewEmbedder`.
## Nomenclature
The term **view** can be ambiguous in `ExternalViewEmbedder`, and therefore the following terms are used:
* A **native view** refers to the final drawing surface that to composite layers to. It is the "view" used in other places of the engine, such as `Shell::AddView`.
* A **platform view** refers a platform view, a layer that holds content to be embedded.
## Change
The lifecycle of `ExternalViewEmbedder` is changed:
<table>
<thead>
<tr>
<th>Before PR</th>
<th>After PR</th>
<th>How it's called</th>
</tr>
</thead>
<tbody>
<tr>
<td rowspan=2>BeginFrame</td>
<td>BeginFrame</td>
<td>Once per frame</td>
</tr>
<tr>
<td>PrepareFlutterView</td>
<td>Once per flutter view</td>
</tr>
<tr>
<td>SubmitFrame</td>
<td>SubmitFlutterView (renamed)</td>
<td>Once per flutter view</td>
</tr>
<tr>
<td>EndFrame</td>
<td>EndFrame (unchanged)</td>
<td>Once per frame</td>
</tr>
</tbody>
</table>
* `BeginFrame` should perform per-frame actions, such as merge-unmerging threads.
* `PrepareView` should perform per-native-view preparations, such as recording the view ID and view size.
This change is necessary because some actions in `PrepareView` needs to be refreshed at the beginning of drawing every native view.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Fixes https://github.com/flutter/flutter/issues/138373
When constructing overlay layers when there are platform views, make sure the same pixel format and color space as the main view is used.
Add validation to impeller HAL about blitting different pixel formats.
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.
This PR moves expat, ocmock, libjpeg-turbo, libwebp, and wuffs to
//flutter/third_party.
It also deletes //third_party/fontconfig, which was unused.
In cases where we subclassed gtest fixtures purely to get better naming for test output (i.e. displaying/filtering on AccessibilityBridgeMacTest instead of AutoreleasePoolTest, replace these with `using` declarations, which is equally effective and avoids actually subclassing.
This applies no semantic changes to the code or tests.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Runs all FlutterMenuPlugin tests in an AutoReleasepoolTest, which
ensures all allocations are cleaned up.
Also extracts out some hackery into the FlutterMenuPluginTest fixture to
ensure that NSApplication instantiates everything necessary to do menu
bar manipulation.
Also replaces the use of OCMock in FlutterMenuPluginTest.mm with a fake
FakePluginRegistrar class. This avoids unnecessary use of OCMock in the
tests, which has been responsible for flakiness in some tests, in
particular where the mock is used across threads. This test was not
problematic, but the fake makes the tests more readable.
Also fixes linter warnings about using NSLocalizedString for user-facing
strings.
Issue: https://github.com/flutter/flutter/issues/104789
Issue: https://github.com/flutter/flutter/issues/127441
Issue: https://github.com/flutter/flutter/issues/124840
Introduce weak_nsobject from chromium.
There are some usages of weak_ptr wrapping Objective-C ids, weak_ptr is not really designed for ids and such usages are blocking the arc migration.
This PR mostly copies the weak_nsobject from chromium, at the same hash that we copied the ARC/MRC compatible scoped_nsobject: fd625125b8
To match how we used weak_ptr for those ids, I made some changes to the weak_nsobject:
- WeakNSObjects needs to be generated by a WeakNSObjectFactory. The WeakNSObjectFactory is owned by the objc class and acts as the generator of the WeakNSObjects. All the WeakNSObjects' derefing thread should be the same of the WeakNSObjectFactory's creation thread.
- chromuim's WeakNSObjects can be detached from the thread and re-attached to a new thread. To match our weak_ptr behavior, I changed WeakNSObjects to be only accessed from a single thread, the same as weak_ptr
This PR also moves the FlutterEngine to use WeakNSObject and updated related classes.
part of https://github.com/flutter/flutter/issues/137801
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
This PR hides the system highlights in iOS 16 (except when scribble is enabled).
Note that auto correction highlight is still drawn by flutter, so it still works.
I don't think we need to CP this, since it's iOS 16 only, and iOS 17 is already out.
## Why not use system highlight?
Unlike iOS 17, the iOS 16 system highlight only respect the width provided by `firstRectForRange`, but not the height. I have audited all sizing related APIs in UITextInput (doc [here](https://developer.apple.com/documentation/uikit/uitextinput#1653155)), specifically, `firstRect(for:)`, `caretRect(for:)` and `selectionRects(for:)`, and they all return the correct height.
## About scribble
The initial implementation of `firstRectForRange` (that returns the first selection rect) was introduced for the scribble feature on iPad (code [here](1d3165a31c (diff-4c7b102c0690b8ec5e2212b079f5d69fe3f816c84e47ce94bc7bc89312f39e40R1487-R1505))).
It turns out that a non-zero rect is required for scribble's advanced feature to work (e.g. inserting a space with a vertical bar). So we can't apply this fix for scribble.
*List which issues are fixed by this PR. You must list at least one issue.*
Fixes https://github.com/flutter/flutter/issues/136802
*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
After close examination of the UIKit's default string tokenizer, when querying the line enclosing the end of doc position **in forward direction**, we should return nil (regardless whether the position is forward or backward affinity).
This aligns with the [API doc](https://developer.apple.com/documentation/uikit/uitextinputtokenizer/1614464-rangeenclosingposition?language=objc):
> If the text position is at a text-unit boundary, it is considered enclosed only if the next position in the given direction is entirely enclosed.
Will cherry pick this soon. Otherwise it will be less and less important as users upgrade to iOS 17.1.
### Why my previous workaround also works?
It turns out my previous workaround PR https://github.com/flutter/engine/pull/46591 works only because our misuse of text affinity in our text input. Specifically, when adding text affinity support, we only added it to `FlutterTextPosition`, but not `FlutterTextRange`. So when getting the beginning/end position from the range, we assign arbitrary affinities.
*List which issues are fixed by this PR. You must list at least one issue.*
https://github.com/flutter/engine/pull/46591
*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
