A semantic node may be tappable without having a more concrete role set on it, such as "button". It will just have a tap handler. This could lead to the sized span to be chosen as the label representation. However, when pointer events land on the span the DOM `target` becomes the span rather than the tappable element, and that breaks the debouncing logic in `pointer_binding.dart`.
This PR removes pointer event handling from inert text spans. This fixes the click debounce logic.
Fixes https://github.com/flutter/flutter/issues/151265
Reverts: flutter/engine#53688
Initiated by: jiahaog
Reason for reverting: canvaskit.js cannot be loaded in an internal end to end test - see b/350885206
Original PR Author: eyebrowsoffire
Reviewed By: {ditman}
This change reverts the following previous change:
This is an attempt to reland https://github.com/flutter/engine/pull/52023. The issue previously is that if it was not specified by the user, the default CanvasKit base URL did not have a leading slash, which does not work when doing dynamic imports.
This is an attempt to reland https://github.com/flutter/engine/pull/52023. The issue previously is that if it was not specified by the user, the default CanvasKit base URL did not have a leading slash, which does not work when doing dynamic imports.
Reverts flutter/engine#53360
Breaking google3 in b/350131288.
There is a test that does something like the following, to check if a radio button is selected.
```dart
// Send a bunch of tabs to focus on the correct radio button
await tester.sendKeyEvent(LogicalKeyboardKey.tab);
await tester.pump();
await tester.sendKeyEvent(LogicalKeyboardKey.tab);
await tester.pump();
await tester.sendKeyEvent(LogicalKeyboardKey.tab);
await tester.pump();
// Toggle the radio button with space
await tester.sendKeyEvent(LogicalKeyboardKey.space);
await tester.pump();
final selectedRadio =
tester.widget<Radio<bool>>(find.byType(Radio<bool>).at(1));
expect(selectedRadio.value, isTrue);
```
After this commit, the above test fails. See the linked bug above for more details.
Reverts: flutter/engine#52023
Initiated by: eyebrowsoffire
Reason for reverting: Causing issues in engine -> framework roll https://github.com/flutter/flutter/pull/151139
Original PR Author: eyebrowsoffire
Reviewed By: {ditman}
This change reverts the following previous change:
This changes CanvasKit and Skwasm to be compiled and loaded as ES6 modules instead of as vanilla script tags. Currently, the emscripten JS files try to register themselves with require.js or AMD module loading systems. We suspect this is causing issues (https://github.com/flutter/flutter/issues/149565) with DDC's module loading system, which itself uses require.js.
This is probably also the fix for https://github.com/flutter/flutter/issues/147731
This changes CanvasKit and Skwasm to be compiled and loaded as ES6 modules instead of as vanilla script tags. Currently, the emscripten JS files try to register themselves with require.js or AMD module loading systems. We suspect this is causing issues (https://github.com/flutter/flutter/issues/149565) with DDC's module loading system, which itself uses require.js.
This is probably also the fix for https://github.com/flutter/flutter/issues/147731
https://dart-review.googlesource.com/c/sdk/+/370663 makes
ExternalDartReference generic. By doing so, it triggers two
cast_nullable_to_non_nullable lints that need to be silenced for it to
land. Once the above SDK changes land, this can be refactored to utilize
the generic and avoid the manual cast altogether.
There were two issues here:
1) We have to stop using the emscripten thread scheduling APIs, as they can be invoked out of order from the rest of the messages that are posted. In some cases, out of order message handling can cause the request for reading pixels in an image to be serviced before some of the texture sources have been transfered to the web worker.
2) Skia's `readPixels` fails if there is is a lazy picture image made from a picture that contains a lazy texture image. The pertinent bug is here: https://g-issues.skia.org/issues/349201915
To work around the Skia bug, we just render the image itself onto our scratch canvas and pull the pixels out with `glReadPixels`.
This fixes https://github.com/flutter/flutter/issues/141326
This fixes an issue where in CanvasKit builds, uniforms set in setFloat function in the Paint class don't get updated after the initial render.
For example, like in the issue linked below, having a shader that animates a value over time and you want to reuse the Paint object that the shader is set to.
I'm no expert with CanvasKit nor with the Flutter Engine, but from what I could tell it seemed that the uniforms were only being sent to Skia on creation of the shader via _makeEffect.
However, any uniforms set afterwords were just stored in a local dart-side List<double> and forgotten about.
This PR changes the List<double> to use a WASM backed SkFloat32List to keep the references to the uniforms linked to dart-side.
fixes https://github.com/flutter/flutter/issues/149800
The Vertices objects are already allocated in a shared object by default so copying them inline into the recording buffer is usually a waste of time rather than reusing the memory allocated for the shared object by recording a reference. Note that the shared DlVertices objects already inline all of their data so we have good data locality as it is without further copying the data into the buffer.
Might help with https://github.com/flutter/flutter/issues/150513
This reverts commit b16181fe6adf18f448058fd4e68ceb4f78f601ab (#52913).
This relands commit f73900ba16ab3873c7f631ab321d4f0ac0194a8e (#52885).
Previously, the `gen_snapshot_arm64` and `gen_snapshot_x64` binaries used by the tool were all built for x64 architecture. As such, developers building apps with Flutter rely on Rosetta translation with every build.
This refactors the gen_snapshot build rules on macOS hosts to consistently produce `gen_snapshot_arm64` and `gen_snapshot_x64` binaries with the target architecture of the build but with as universal binaries with both host architectures.
## arm64 host build
Prior to this patch we emitted:
* gen_snapshot_arm64 (arch: x64, target_arch: simarm64)
After this patch, we emit:
* artifacts_x64/gen_snapshot_arm64 (arch: x64, target_arch: simarm64)
* artifacts_arm64/gen_snapshot_arm64 (arch: arm64, target_arch: arm64)
* gen_snapshot_arm64 (universal binary composed of both of the above)
## x64 host build
Prior to this patch we emitted:
* gen_snapshot_x64 (arch: x64, target_arch: x64)
After this patch, we emit:
* artifacts_x64/gen_snapshot_x64 (arch: x64, target_arch: x64)
* artifacts_arm64/gen_snapshot_x64 (arch: arm64, target_arch: simx64)
* gen_snapshot_x64 (universal binary composed of both of the above)
Note that host builds on macOS currently default to a host architecture of x64 (can be overridden via `--force-mac-arm64`) regardless of host architecture and thus, the build itself relies on Rosetta translation when invoked on Apple Silicon arm64 hardware. This is to ensure a consistent build in CI regardless of bot architecture. See: 0d2b0cd0ed/tools/gn (L502-L505)
Issue: https://github.com/flutter/flutter/issues/101138
Issue: https://github.com/flutter/flutter/issues/69157
Related issue: https://github.com/flutter/flutter/issues/103386
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Adds createImageFromTextureSource for flutter web, exposed in dart:web_ui.
```dart
final ui.Image uiImage = renderer.createImageFromTextureSource(bitmap,
width: 150, height: 150, transferOwnership: false);
```
In canvaskit renderer, this will use MakeLazyImageFromTextureSource. In SkWasmRenderer, it will call imageCreateFromTextureSource, which was already implemented in SkWasm for createImageFromImageBitmap to use, but was not exposed in a way that it could be taken advantage of.
By default, createImageFromTextureSource will create a copy of the object it is passed, but transferOwnership: true may be specified to allow transferable objects to be transferred to the renderer, avoiding the copy.
Fixes: https://github.com/flutter/flutter/issues/150479
Fixes: https://github.com/flutter/flutter/issues/144815
Reverts: flutter/engine#51009
Initiated by: jiahaog
Reason for reverting: This causes b/348598454. We're getting test failures with stack traces like the following after this PR:
```
Cannot get renderObject of inactive element.
In order for an element to have a valid renderObject, it must be active, which means it is part of the tree.
Instead, this element is in the _ElementLifecycle.inactive state.
If you called this method from a State object, consider guarding
```
Original PR Author: tugorez
Reviewed By: {mdebbar}
This change reverts the following previous change:
Fix focus management for text fields
This PR:
1. Refactors the DOM `focus` function to take [options][1]
2. Removes the timers sorrounding the `activeDomElement.focus()` so that the input elements get focused as immediate as possible.
3. Prevents the default on pointerdown in a Flutter View and schedules a `requestViewFocusChange` to claim focus in that view after some time. This gives `2` the opportunity to focus the right `<input />` or `<textarea />` element. This helps focus correctly transition from one input element to another (without jumping to a flutter view in between).
4. Deactivating a `TextField` doesn't blur the focused element anymore, it insteads schedules for later a call to move the focus to the flutter view if nothing inside it claimed focus first.
5. Prevents scroll in all the focus calls (this should help with the view jumping when focusing one text field after another).
## Sample apps
1. Full screen mode: https://tugorez.com/flutter_focus_web
2. Embedded mode: https://tugorez.com/flutter_focus_web?embedded
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
## Description
This PR prevents new line key event from being dispatched for a multiline text field when `TextField.textInputAction` is not `TextInputAction.newline`.
Since https://github.com/flutter/engine/pull/33428, web engine does not prevent new line key events.
In https://github.com/flutter/engine/pull/36893, I fixed a similar issue for single line text fields. At that time I was not sure if we want to fix it for multiline text fields. I checked again on non-web platforms (macos, iOS, Android) and the new line is not added if the input action is not `TextInputAction.newline`.
For a **multiline field**, the default text input action is `TextInputAction.newline`.
If the developer sets text input action to another value:
- before this PR, the action is performed and a new line is added.
- after this PR, the action is performed but no new line is added.
## Related Issue
Fixes https://github.com/flutter/flutter/issues/145051
## Tests
Adds 1 tests, updates 3 tests.
Fix focus management for text fields
This PR:
1. Refactors the DOM `focus` function to take [options][1]
2. Removes the timers sorrounding the `activeDomElement.focus()` so that the input elements get focused as immediate as possible.
3. Prevents the default on pointerdown in a Flutter View and schedules a `requestViewFocusChange` to claim focus in that view after some time. This gives `2` the opportunity to focus the right `<input />` or `<textarea />` element. This helps focus correctly transition from one input element to another (without jumping to a flutter view in between).
4. Deactivating a `TextField` doesn't blur the focused element anymore, it insteads schedules for later a call to move the focus to the flutter view if nothing inside it claimed focus first.
5. Prevents scroll in all the focus calls (this should help with the view jumping when focusing one text field after another).
## Sample apps
1. Full screen mode: https://tugorez.com/flutter_focus_web
2. Embedded mode: https://tugorez.com/flutter_focus_web?embedded
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Safari actually pauses execution of our unit tests if the window becomes occluded or non-visible. As such, I am inserting this egregious hack which just makes the Safari window frontmost every 2 seconds so that the unit tests don't get stalled out.
This should fix https://github.com/flutter/flutter/issues/150023
…#53134)"
This reverts commit f1978535f0355491a67a07ddaf87297361e90d83.
Reverting because the engine PR landed prematurely. It needs to wait for
a framework change, otherwise, things will break.
Stop using `SemanticsAction.didGain/LoseAccessibilityFocus` on the web, start using `SemanticsAction.focus`. This is because on the web, a11y focus is not observable, only input focus is. Sending `SemanticsAction.focus` will guarantee that the framework move focus to the respective widget. There currently is no "unfocus" signal, because it seems to be already covered: either another widget gains focus, or an HTML DOM element outside the Flutter view does, both of which have their respective signals already.
More details in the discussion in the issue https://github.com/flutter/flutter/issues/83809.
Fixes https://github.com/flutter/flutter/issues/83809
Fixes https://github.com/flutter/flutter/issues/148285
Fixes https://github.com/flutter/flutter/issues/143337
Users of packages that have specialized code for the VM (which supports
FFI) use conditional imports based on `dart.library.ffi`. We don't want
the VM-specific code to be used for web in dart2wasm.
As a result we're going to make `dart.library.ffi` be false in
conditional imports (as well as in
`const bool.fromEnvironment('dart.library.ffi')`).
Issue https://github.com/dart-lang/sdk/issues/55948
Issue https://github.com/flutter/flutter/issues/149984
The issue in [0] was fixed. So we no longer have to use conditional
imports and dart2wasm vs dart2js specific implementations.
Instead we use the new extension methods introduced due to [0], namely
`Object.toExternalReference` and `ExternalDartReference.toDartObject`.
[0] https://github.com/dart-lang/sdk/issues/55183
Adds a function to each 'wheel' DataPacket sent to the framework so it can signal whether to `allowPlatformDefault` or not.
The current default is to always `preventDefault` on browser events that get sent to the framework.
This PR enables the framework to call a method on the `DataPacket`s to `allowPlatformDefault: true`, if the framework won't handle the Signal (signals are handled synchronously on the framework).
This lets the engine "wait" for the framework to decide whether to `preventDefault` on a `wheel` event or not.
## Issues
* Needed for: https://github.com/flutter/flutter/issues/139263
## Tests
* Added unit tests for the feature in the engine repo, veryfing whether the event has had its `defaultPrevented` or not.
* Manually tested in a demo app (see below)
## Demo
* https://dit-multiview-scroll.web.app
<details>
<summary>
## Previous approaches
</summary>
1. Add a `handled` bool property to `PointerDataPacket` that the framework can write to (brittle)
2. Modifications to the `PlatformDispatcher` so the framework can `acknowledgePointerData` with a `PointerDataResponse` (fffffatttt change)
3. `acknowledge` function in `PointerDataPacket`
</details>
> [!IMPORTANT]
> * Related: https://github.com/flutter/flutter/pull/145500
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
`always_specify_types: false` and `avoid_dynamic_calls: false` is a dangerous combination. Let's clean up `avoid_dynamic_calls` before disabling `always_specify_types`.
Based on the (internal) discussion around converging on using the official Dart style guide, the design discussion https://flutter.dev/go/use-dart-style-in-flutter-engine, and with the exception of the code that gets published under `dart:ui` (as that is user-facing, and we'd like to evolve the code style in conjunction with the framework), we're going to be (gradually) adopting the Dart style guide in `flutter/engine`.
For now, we:
- Remove `always_specify_types` (except for `lib/ui`, i.e. `dart:ui`)
- Re-enable `type_annotate_public_apis` (which is now relevant since the above is disabled)
- Announce our _intent_ to re-format and apply the Dart formatter (which we'll land in the near future)
---
I also took the opportunity to specify more about our style guide use in general, mostly to make it easier to understand our conventions, and also call out known problem areas (notably, our over-use of `shared_ptr` and `auto` in some cases). I am happy to split those up, but it was easier to make the markdown changes at once.
I also took @cbracken and folks advice and clarified directly that explicit types in Dart are _not_ bad (with examples).
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
