This change adds a new property in Semantics widget that would take an integer value corresponding to the heading levels defined by the ARIA heading role. This is necessary in order to get proper accessibility and usability in a website for users who rely on screen readers and other assistive technologies.
Issue fixed by this PR:
https://github.com/flutter/flutter/issues/97894
Framework part:
https://github.com/flutter/flutter/pull/125771
fix cursor hit testing in platform view in #52159
We found that the mechanism of `[NSView hitTest: view] `will handle the
flip coordinate automatically. In the previous PR, because the superview
of FlutterView was not flipped, we should not convert the point using
`[self convertPoint:event.locationInWindow fromView:nil]` .The
FlutterView hit test should run under the window coordinate system;
otherwise, FlutterMutatorView will hit a wrong point.
Before the fix:
Actual mouse move: `event.locationInWindow (x = 47.45703125, y =
416.86328125)`
FlutterView HitTest: `(NSPoint) point = (x = 47.45703125, y =
203.13671875)`
FlutterMutatorView HitTest: `(NSPoint) point = (x = 47.45703125, y =
416.86328125)`
After the fix:
Actual mouse move: `event.locationInWindow (x = 47.45703125, y =
416.86328125)`
FlutterView HitTest: `(NSPoint) point = (x = 47.45703125, y =
416.86328125)`
FlutterMutatorView HitTest: `(NSPoint) point = (x = 47.45703125, y =
203.13671875)`
## 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.
If you need help, consider asking for advice on the #hackers-new channel
on [Discord].
<!-- Links -->
[Contributor Guide]:
https://github.com/flutter/flutter/wiki/Tree-hygiene#overview
[Tree Hygiene]: https://github.com/flutter/flutter/wiki/Tree-hygiene
[test-exempt]:
https://github.com/flutter/flutter/wiki/Tree-hygiene#tests
[Flutter Style Guide]:
https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo
[C++, Objective-C, Java style guides]:
https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
[testing the engine]:
https://github.com/flutter/flutter/wiki/Testing-the-engine
[CLA]: https://cla.developers.google.com/
[flutter/tests]: https://github.com/flutter/tests
[breaking change policy]:
https://github.com/flutter/flutter/wiki/Tree-hygiene#handling-breaking-changes
[Discord]: https://github.com/flutter/flutter/wiki/Chat
For devices with 1 fast core, the current affinity set is less idea because it forces UI and raster on the same thread. Widen this to exclude slow cores instead of including only the fast core.
In https://github.com/flutter/buildroot/pull/860, disabling `NSAssert` in release build was added, and https://github.com/flutter/engine/pull/53005 tries to roll the change into the engine. However, the change is blocked due to several compilation errors in the engine.
This is due to the fact that Google's `DCHECK`(in flutter engine, `FML_DCHECK`) does not make unused variable warning even in release build, while traditional assertion macro like `assert` or `NSAssert` does. For example, the following code will be expanded like this:
code:
```c++
FML_DCHECK(status == kCVReturnSuccess && pxbuffer != nullptr) <<
"Failed to create pixel buffer";
```
expanded code:
```c++
true || (status == kCVReturnSuccess && pxbuffer != nullptr)
? (void)0 ::
: fml::LogMessageVoidify() &
::fml::LogMessage(::fml::kLogFatal, 0, 0, nullptr).stream()
```
However, equivalent code with `NSAssert` will make unused variable warning, since the expanded code doesn't have any reference to the variable:
code:
```c++
NSAssert(status == kCVReturnSuccess && pxbuffer != NULL, @"Failed to create pixel buffer.");
```
expanded code:
```c++
do {
} while (0)
```
To unblock the build, this CL replaces several `NSAssert` with `FML_DCHECK` in the engine codebase. This CL isn't aimed to replace all `NSAssert` with `FML_DCHECK` since discussions in https://github.com/flutter/buildroot/pull/860 are not finalized whether to replace all `NSAssert` with `FML_DCHECK` or not.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Reverts: flutter/engine#53099
Initiated by: jonahwilliams
Reason for reverting: manifest opt out doens't work.
Original PR Author: jonahwilliams
Reviewed By: {bdero, zanderso, chinmaygarde}
This change reverts the following previous change:
All plugin migrations have landed. Enable impeller by default on Android.
Reverts: flutter/engine#53108
Initiated by: jonahwilliams
Reason for reverting: Probably --no-enable-impeller isn't working
Original PR Author: jiahaog
Reviewed By: {jonahwilliams}
This change reverts the following previous change:
After https://github.com/flutter/engine/pull/53099, impeller is always enabled, even if the manifest disables it using `io.flutter.embedding.android.EnableImpeller`.
This PR causes it to respect the manifest value if it is explicitly disabled.
Fixes b/343603270
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Add `SemanticsAction.focus`. This PR just adds the new enum value without any logic. Adding the enum value first to unblock work that needs to be done on both the engine and framework side that will actually implement all the necessary logic.
This is PR 1 out of ~3 for https://github.com/flutter/flutter/issues/83809
Revert label failed due to conflicts
`FlutterFragmentTest.java` was the only file that had merge issues, everything else is the output of `git revert 802e5d2cd3c9e73f336e3fe43487b64a5fdf98d8`
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Android add-to-app apps now support predictive back when going between Activities or back to the home screen. Predictive back route transitions within the Flutter part of the app are not yet supported.
Upgrades every `androidx` dependency in the `src/third_party/android_embedding_dependencies` bundle to the latest version, except the `lifecycle` group*. Tested running a couple of apps as well because when updating these dependencies in the past I've been able to build the engine but then flutter run fail when trying to run an app.
Fixes https://github.com/flutter/flutter/issues/129307, also unblocks a feature that will eventually be needed for Scribe.
[*]`2.8.0` is the latest there, but I ran into an issue with dexing when I tried to upgrade, due to b/336164417, an AGP bug that had its fix backported to all >`8.0.0` versions, but we still support less than that so we will have to wait on that upgrade.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
This patch addresses the missing implementation of
`platformDispatcher.views` on Linux. It checks the refresh rate of the
renderer's window and returns the value. Without this implementation,
`WidgetsBinding.instance.platformDispatcher.views.first.display.size`
would throw an exception on Linux, preventing safe usage.
Related: https://github.com/flutter/flutter/issues/144230
When you background an activity via the back-gesture the onTrimMemory callback is not invoked but the buggy Android behaviour still occurs.
Workaround this by faking an onTrimMemory callback in the `Activity#onStop` callback.
Fixes#148662
Related #146499
Tested manually on a Pixel 7 Pro running Android 14.
Work towards https://github.com/flutter/flutter/issues/139702.
I think we should also `@Deprecate`/cleanup the API surface in
`FlutterView`, but that needs a bit more a discussion.
/cc @johnmccutchan
1. Migrate TextInputSemanticsObject to ARC
2. Rename the Objective-C-only `accessibility_text_entry.*` files to `TextInputSemanticsObject.*`
3. Move `FlutterInactiveTextInput` interface from the header file into the implementation, the only place it's used.
Blocked on `SemanticsObject` ARC migration https://github.com/flutter/engine/pull/52824
Part of https://github.com/flutter/flutter/issues/137801.
Split the too-large `Semantics` [MRC to ARC migration](https://github.com/flutter/flutter/issues/137801) into two PRs: this one, which refactors, and the next which will actually do the migration.
1. Use properties instead of their backing ivars (except in the usual init, dealloc, getters/setters)
2. For Foundation collections prefer `copy` over `strong`.
3. Dot notation for properties
4. Change `privateSetParent:` to instead use a `readwrite` property in `SemanticsObject ()`.
5. Switch the `semanticsObject` property from `weak` to `retain` to get the synthesized property (keeping it as `weak` is a compilation error in MRC) but I'll swap it back to a `weak` in the ARC migration PR coming next.
6. `SemanticsObjectTest` fails on my machine and passes on CI. Switched the cleaner `CGRectEqualToRect` (and related) checks to instead assert x, y, width, height so we can see the value when it fails:
```
((CGSizeEqualToSize( scrollView.contentSize, CGSizeMake((w + scrollExtentMax) * effectivelyScale, h * effectivelyScale))) is true) failed
```
becomes:
```
((scrollView.contentSize.height) equal to (h * effectivelyScale)) failed: ("33.3333333333") is not equal to ("33.333336")
```
Use `XCTAssertEqualWithAccuracy` now that I can see it's a floating point precision issue.
The size of the LTO build of the engine with the dylib compressed is as follows:
```sh
$ du -k libFlutter*
5236 libFlutter.dylib.tar.gz
4324 libFlutterSlimpeller.dylib.tar.gz
```
Sizes are in KiB. This represents a binary size reduction of 17.41% of the compressed artifacts. The compression ratios will likely differ based on the compression scheme.
Uncompressed, the sizes are:
```sh
$ du -k libFlutter*
16920 libFlutter.dylib
14044 libFlutterSlimpeller.dylib
```
This represents a binary size reduction of 16.99% which is in the same ballpark.
The really mucky bit was backing out the raster cache and persistent cache. I want to clean that up in a later patch so that those TUs are part of a separate submodule.
Opting out of Impeller will lead to a fatal log at startup saying the opt-out is disallowed.
Fixes https://github.com/flutter/flutter/issues/126606
- Migrate `FlutterDartProject` and `FlutterPluginAppLifeCycleDelegate` from MRC to ARC.
- Swap a few dictionary `objectForKey:` to subscripting.
- Header cleanup.
- Cleanup build DEPS.
Part of https://github.com/flutter/flutter/issues/137801.
I found this while migrating `FlutterPlatformViews_Internal.mm` to ARC https://github.com/flutter/engine/pull/52535. I'll land this first.
```objc
if (_backdropFilterView != visualEffectView) {
_backdropFilterView = [visualEffectView retain];
}
```
should instead be something like:
```objc
if (_backdropFilterView != visualEffectView) {
id oldBackdropFilterView = _backdropFilterView;
_backdropFilterView = [visualEffectView retain];
[oldBackdropFilterView release];
}
```
But that's already what the built-in MRC `nonatomic, retain` property setter does, so use that instead.
Added a test that passes on this PR and fails on main.
This doesn't yet add support for backdrop filters or emulated advanced blends, but will allow them to work if `surface_frame.framebuffer_info().supports_readback` is true.
part of https://github.com/flutter/flutter/issues/142054
The observed behavior is that if a keypress both reach framework and flutter textinputplugin selector and the keypress handler in framework causes the the textinputplugin to resign first responder, the selector will still go through even if the textinputplugin has already resigned.
The pr makes it so textinputplugin will ignore these selector call
fixes https://github.com/flutter/flutter/issues/143270
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
This wires up Android Hardware Buffer backed swapchains on platform that support
it (Android >= 29) with a KHR swapchain fallback (which can be removed later to
save on some binary size if needed).
Some salient features of these swapchains and their differences with the KHR
variant:
* All swapchain images are guaranteed to R8G8B8A8. This could potentially allow
for earlier creation of the context and the PSO libraries.
* All swapchain allocations are lazy. This should greatly reduce the time it
takes to create and resize a swapchain. However, swapchain image acquisition
may take longer for the first few frame where there is no pre-pooled image
available. Resizes should be similarly faster since the swapchain images for
the intermediate sizes are never created.
* Swapchain transients allocations (the attachments for the root render target)
are also lazily allocated.
* Swapchain images are pool and reused. The size of the pool is user specified
(currently 2). If an image in the pool ages past a user supplied value
(currently 1 second), it is collected as well. Applications that don't render
frames for a long period of time should see less memory use because of
swapchain image allocations.
* The present mode of AHB swapchains behave similar to KHR swapchains but with
VK_PRESENT_MODE_MAILBOX_KHR. In cases where there is no application managed
frame pipelining, this might cause images to never be presented if a newer
image is available. This wasted work can only be avoided by application
provided pipelining.
* There are no client side waits during image presentation. Instead, a new type
of fence is wired up that exports its state as a sync file descriptor. The
fence signal operation is enqueued on the client side and the buffer is set on
the surface control. The presentation engine then performs the wait.
* On Qualcomm devices, Chromium seems to be setting vendor specified flags for
opting the hardware buffers into using UBWC. AFAICT, this is similar to AFBC
(and NOT AFRC) on ARM Mali. This has not been wired up since I don't have a
Qualcomm device at the moment and cant verify bandwidth use using GPU
counters. I would also like to verify that UBWC is safe to use to images that
can be used as input attachments.
This removes goma most places except for the arguments to the `gn`
script, which are referenced by recipes. This does not remove goma
capabilities from the GN build entirely. That requires changes in the
buildroot which have to be staged after this change.
