<!-- start_original_pr_link -->
Reverts: flutter/flutter#168996
<!-- end_original_pr_link -->
<!-- start_initiating_author -->
Initiated by: zanderso
<!-- end_initiating_author -->
<!-- start_revert_reason -->
Reason for reverting: Failing in post submit on
web_long_running_tests_3_5
<!-- end_revert_reason -->
<!-- start_original_pr_author -->
Original PR Author: eyebrowsoffire
<!-- end_original_pr_author -->
<!-- start_reviewers -->
Reviewed By: {mdebbar}
<!-- end_reviewers -->
<!-- start_revert_body -->
This change reverts the following previous change:
The lifecycle of `Path` objects are currently not managed by the user.
That is to say, there is no `dispose` method on path objects and
therefore no explicit way to detect when the user is done with the path
object and the native-side object can be exposed. As of right now, we
use `FinalizationRegistry` to clean up the native-side objects when the
dart-side objects are garbage collected. However, this has a number of
issues:
* Adding objects to the finalization registry actually ends up
prolonging their lifetime in V8, since the V8 garbage collector will
only collect them in a major GC and not a minor GC once they are
registered with the finalization registry. See the following Chrome bug:
https://issues.chromium.org/issues/340777103
* We can run into OOM issues where the linear memory of canvaskit/skwasm
exceeds 2GB if the collection of paths go on too long.
* Even if the paths do get collected by the GC, they often happen
infrequently enough that paths over many frames have accumulated and are
being collected all at once. This gap can often be dozens or hundreds of
frames long, and when collection does occur it is freeing a lot of paths
at once, which causes a janky frame. I have seen this take upwards of
800ms on my M1 Macbook Pro.
There are some more details in
https://github.com/flutter/flutter/issues/153678
This PR alleviates this issue by creating a `LazyPath` object. This
object is added to an arena that explicitly collects the underlying
native objects at the end of each frame. The object also tracks the API
calls made to it so that if it is actually used across a frame boundary
that we can recreate the native object if it was freed.
Running our benchmarks, this has a non-trivial performance cost to
building and using these paths (30-50% in a microbenchmark, 3-6% in a
broader full app benchmark). However, as a team we've decided that this
cost is worth it to avoid OOM issues as well as the non-deterministic
jank associated with large collections of these objects.
<!-- end_revert_body -->
Co-authored-by: auto-submit[bot] <flutter-engprod-team@google.com>
The lifecycle of `Path` objects are currently not managed by the user.
That is to say, there is no `dispose` method on path objects and
therefore no explicit way to detect when the user is done with the path
object and the native-side object can be exposed. As of right now, we
use `FinalizationRegistry` to clean up the native-side objects when the
dart-side objects are garbage collected. However, this has a number of
issues:
* Adding objects to the finalization registry actually ends up
prolonging their lifetime in V8, since the V8 garbage collector will
only collect them in a major GC and not a minor GC once they are
registered with the finalization registry. See the following Chrome bug:
https://issues.chromium.org/issues/340777103
* We can run into OOM issues where the linear memory of canvaskit/skwasm
exceeds 2GB if the collection of paths go on too long.
* Even if the paths do get collected by the GC, they often happen
infrequently enough that paths over many frames have accumulated and are
being collected all at once. This gap can often be dozens or hundreds of
frames long, and when collection does occur it is freeing a lot of paths
at once, which causes a janky frame. I have seen this take upwards of
800ms on my M1 Macbook Pro.
There are some more details in
https://github.com/flutter/flutter/issues/153678
This PR alleviates this issue by creating a `LazyPath` object. This
object is added to an arena that explicitly collects the underlying
native objects at the end of each frame. The object also tracks the API
calls made to it so that if it is actually used across a frame boundary
that we can recreate the native object if it was freed.
Running our benchmarks, this has a non-trivial performance cost to
building and using these paths (30-50% in a microbenchmark, 3-6% in a
broader full app benchmark). However, as a team we've decided that this
cost is worth it to avoid OOM issues as well as the non-deterministic
jank associated with large collections of these objects.
**Summary**
This PR improves web accessibility in Flutter by separating hint from
label in the semantics engine and exposing them via ARIA attributes. The
hint is set using aria-description (or aria-describedby as a fallback
for browsers that do not support aria-description).
**Details**
Hint separation:
The hint is exposed via aria-description if supported, or via
aria-describedby with a hidden node as a fallback.
Browser compatibility:
Uses feature detection to choose between aria-description and
aria-describedby.
Test coverage:
Added/updated tests to verify correct ARIA attribute behavior and
fallback logic.
**How to verify**
All relevant tests pass (semantics_test.dart, semantics_text_test.dart).
**Motivation**
This change brings Flutter web closer to accessibility best practices
and ARIA standards, improving the experience for users of assistive
technologies.
**Before/After Change**
before: https://before-change-hint.web.app/
after: https://after-change-hint.web.app/
after(fallback to aria-describedby):
https://after-change-hint-fallback.web.app/
**Issues fixed**
https://github.com/flutter/flutter/issues/162140
**Note**
Some focus-related tests (e.g., incrementable sends focus events) are
failing, but these failures are also present on the main branch and are
unrelated to the ARIA label/hint changes in this PR.
## 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.
---------
Co-authored-by: Mouad Debbar <mouad.debbar@gmail.com>
Update documentation for `Size` and `Rect` classes in geometry.dart to
correct references for `centerRight` and `bottomCenter` methods.
Co-authored-by: stuuupidcat <stuuupidcat.3@gmail.com>
This adds a debugging utility that allows us to dump counts of the live
skwasm objects in debug mode. This is useful for understanding memory
leaks.
This is not code that runs in production or affects end users, so I'm
not bothering to write specific unit tests for this functionality.
---------
Co-authored-by: Kevin Moore <kevmoo@users.noreply.github.com>
Nearly all parts of the Impeller rendering pipeline now rely on DlPath
and PathSource objects for their path description needs. The impeller
path only exists for impeller's unit tests and benchmarks to have a
local way to construct paths. We implement path construction for the
DlPath object via DlPathBuilder which makes the impeller family of path
objects functionally obsolete and so they are now deleted.
Reduce the number of places where we convert flutter paint to DLpaint
and remove unused tonic overrides. Also does a pass on dl_paint/builder
to remove places we accidentally incremented/decrement shared_ptr ref
counts
<!-- start_original_pr_link -->
Reverts: flutter/flutter#165531
<!-- end_original_pr_link -->
<!-- start_initiating_author -->
Initiated by: matanlurey
<!-- end_initiating_author -->
<!-- start_revert_reason -->
Reason for reverting: Breaks google client tests
<!-- end_revert_reason -->
<!-- start_original_pr_author -->
Original PR Author: ash2moon
<!-- end_original_pr_author -->
<!-- start_reviewers -->
Reviewed By: {chunhtai, reidbaker, hannah-hyj}
<!-- end_reviewers -->
<!-- start_revert_body -->
This change reverts the following previous change:
Resolves partly https://github.com/flutter/flutter/issues/165510
**Context:** This issue originates from
https://github.com/flutter/flutter/issues/99715, where it was reported
that `liveRegion` alone was insufficient for announcing form validation
errors. While `liveRegion` announces the first error encountered,
subsequent submissions with the same error message on Android would not
trigger a re-announcement.
**Original Solution:** Pull request
https://github.com/flutter/flutter/pull/123373 addressed this by
implementing the `announce` event to ensure error messages were
consistently announced, even for repeated submissions.
**Native Android Behavior (Jetpack Compose):** In native Android
development using Jetpack Compose, setting the `isError` property of a
`TextField` to `true` triggers Talkback to announce "Error invalid
input." This announcement occurs *only* on the initial change to the
error state. Subsequent errors, even if the `isError` property remains
`true`, are not re-announced. This behavior closely mirrors the
functionality of `liveRegion`, with the key difference being that
`liveRegion` also announces the specific error text, in addition to the
general error state. Testing in a native Jetpack Compose application
confirms this behavior and provides a valuable comparison point against
the current Flutter form example.
**Suggested Action:** **Fork** the behavior in
https://github.com/flutter/flutter/pull/123373. Reinstate the use of
`liveRegion` for error announcements within `widgets/Form` for Android
and keep other platforms the same.
## 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.
If you need help, consider asking for advice on the #hackers-new channel
on [Discord].
<!-- Links -->
[Contributor Guide]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#overview
[Tree Hygiene]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md
[test-exempt]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#tests
[Flutter Style Guide]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md
[Features we expect every widget to implement]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md#features-we-expect-every-widget-to-implement
[CLA]: https://cla.developers.google.com/
[flutter/tests]: https://github.com/flutter/tests
[breaking change policy]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#handling-breaking-changes
[Discord]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Chat.md
[Data Driven Fixes]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Data-driven-Fixes.md
<!-- end_revert_body -->
Co-authored-by: auto-submit[bot] <flutter-engprod-team@google.com>
**Description**
This pull request removes the unnecessary setAriaRole('dialog') fallback
in the SemanticRoute class within the Flutter web engine. This line was
an old fallback and is no longer needed
**Before**
https://dialog-0505-before.web.app/
**After**
https://dialog-050502-after.web.app/
**Issue Fixed**
This PR addresses GitHub Issue #168247, which proposes reconsidering the
application of role="dialog" to arbitrary routes.
## 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].
- [ ] 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.
This produces a build of Skwasm that works on Firefox and Safari. This
means we use `SkAnimatedImage` for animated gifs and webps and use
builtin ICU data in Skia.
I have unit test suites for Safari and Firefox with dart2wasm and both
`ui` and `engine` test sets. However, there are a few issues with
running these on CI:
* Safari+dart2wasm doesn't work yet until the CI bots are upgraded to
macOS 15, so these have been disabled on CI for now (but you can run the
unit test suite locally).
* Firefox+ui doesn't work because our Linux bots have no GPU and
therefore no WebGL2 support, so that one is disabled. Firefox+dart2wasm
with the `engine` suite is enabled on CI though.
I did make some changes to the host page for our unit test harness so
that Safari actually works though. Even though we're not running on CI,
you can still run locally if you have macOS 15.
In this PR:
- `felt build --experimental-webparagraph` builds a 3rd variant of
CanvasKit to be used for `WebParagraph`.
- `felt test --suite=chrome-dart2js-experimental-webparagraph-ui` runs
`test/ui/` tests against `WebParagraph`.
- `felt test --suite=chrome-dart2js-experimental-webparagraph-ui` runs
Chrome with the extra flag:
- `--enable-experimental-web-platform-features`
In the future:
- Upgrade to Chrome@133.0.6943.53 or above.
- Actual implementation and tests of WebParagraph coming in
https://github.com/flutter/flutter/pull/167559
- Run the `chrome-dart2js-experimental-webparagraph-ui` suite in CI.
- Trim the new experimental build of CK to realize the reduction in
size.
Previously, mnemonics specified in templates that used compiled_action
and compiled_action_foreach would not be forwarded. This made actions
like ImpellerC invocation unable to tag themselves. As Ninja builds
progressed, only a mysterious ACTION label would be emitted for all
ImpellerC edges. Now, the edges tag themselves.
Attempt to speed up vulkan startup by ensuring vulkan driver
initialization happens on raster thread. Prev. we immediately
initialized the impeller::Context, unfortunately setting up the vulkan
context can take upwards of 100ms. This time is running on the platform
thread and blocking startup.
Instead, I attempt to hide/defer as much as possible what backend is
being used - this requires us to access the impeller context via a
shared_future in some cases instead of immediately knowing it is valid.
<!-- start_original_pr_link -->
Reverts: flutter/flutter#167527
<!-- end_original_pr_link -->
<!-- start_initiating_author -->
Initiated by: gmackall
<!-- end_initiating_author -->
<!-- start_revert_reason -->
Reason for reverting: failing postsubmit `Linux_mokey
flutter_engine_group_performance`
<!-- end_revert_reason -->
<!-- start_original_pr_author -->
Original PR Author: jonahwilliams
<!-- end_original_pr_author -->
<!-- start_reviewers -->
Reviewed By: {jason-simmons}
<!-- end_reviewers -->
<!-- start_revert_body -->
This change reverts the following previous change:
Attempt to speed up vulkan startup by ensuring vulkan driver
initialization happens on raster thread. Prev. we immediately
initialized the impeller::Context, unfortunately setting up the vulkan
context can take upwards of 100ms. This time is running on the platform
thread and blocking startup.
Instead, I attempt to hide/defer as much as possible what backend is
being used - this requires us to access the impeller context via a
shared_future in some cases instead of immediately knowing it is valid.
<!-- end_revert_body -->
Co-authored-by: auto-submit[bot] <flutter-engprod-team@google.com>
Attempt to speed up vulkan startup by ensuring vulkan driver
initialization happens on raster thread. Prev. we immediately
initialized the impeller::Context, unfortunately setting up the vulkan
context can take upwards of 100ms. This time is running on the platform
thread and blocking startup.
Instead, I attempt to hide/defer as much as possible what backend is
being used - this requires us to access the impeller context via a
shared_future in some cases instead of immediately knowing it is valid.
This includes a fix for a race seen in
EmbedderTest.PlatformThreadIsolatesWithCustomPlatformTaskRunner
The implementaion of MergedPlatformUIThread::kMergeAfterLaunch required
changing the interface of the TaskObserverAdd/TaskObserverRemove
callbacks so that TaskObserverAdd returned the TaskQueueId where the
observer was added. That TaskQueueId would later be given to
TaskObserverRemove.
The original implementation of this PR updated the embedder library's
implementation of TaskObserverAdd to return TaskQueueId::kInvalid to
signal that the observer was not added. However, this conflicted with
the embedder's EmbedderTaskRunner, whose implementation of
GetTaskQueueId returns TaskQueueId::kInvalid as a placeholder.
This PR reverts the embedder's TaskObserverAdd/TaskObserverRemove to the
original implementation which adds the observer to the current thread's
message loop and does not call GetTaskQueueId.
See https://github.com/flutter/flutter/issues/167418
Fixes https://github.com/flutter/flutter/issues/155265
This includes 2 fixes:
* When the window/iframe loses focus, close the text input connection
instead of grabbing the focus again.
* Do not enable semantics using the placeholder when moving focus using
the "Tab" key.
Bonus: remove the no longer necessary `ViewFocusBinding.isEnabled`
(doesn't fix any issues, just a clean-up).
---------
Co-authored-by: Mouad Debbar <mdebbar@google.com>
If settings.merged_platform_ui_thread is set to kMergeAfterLaunch, then
the engine will be started on the UI thread. After engine setup
completes and the Dart isolate is loaded, the UI task runner will be
merged into the platform thread and all future Dart execution will run
on the platform thread.
This makes it possible for other work to run on the platform thread
while the engine starts.
See https://github.com/flutter/flutter/issues/163064
It turns out `postMessage` is quite a bit more expensive than
`queueMicrotask`. Before dynamic threading, this is what we actually
did, and perf regressed when we started using `postMessage` instead.
This fixes https://github.com/flutter/flutter/issues/166905
This reverts commit 2fc716d, and updates the cross-axis size of the
`_scrollOverflowElement` to be 1px (non-zero), so it is taken into
account by the scrollable elements scrollHeight.
Fixes#160217
## 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.
---------
Co-authored-by: Renzo Olivares <roliv@google.com>
