We are about to `dart format` all the Dart code in the repo, which line-breaks some of our imports.
This PR updates `sdk_rewriter.dart` to support line-broken imports.
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
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
Use the newly exposed functionality in `dart:_wasm` to fix up two different hacks we have:
1) When creating an image from an image source, use `wasm:import` instead of `@Native` and pass the image source directly as an externref. (Direct wasm binding instead of a JS interop shim, yay).
2) When binding the surface callback, previously we were wrapping the callback in a JS function, and then using `WebAssembly.Function` to create a wasm function wrapper around that. Now, we can create a `WasmFuncRef` that is a direct reference to a dart function and pass that over. Now there are no intermediary JavaScript layers when skwasm calls back to us, and we no longer are dependent on the type reflection flag in Chrome.
This fixes https://github.com/flutter/flutter/issues/134556
* Consolidate and check JavaScript access
* Remove all `ignore: implicit_dynamic_function`
* Add `js_access_test.dart` that validates JS access
* Make `engine.dart` an exports-only library
* Fix `sdk_rewriter_test.dart` and `ci/analyze.sh` (they skipped some tests)
[Re-land] Add SPIR-V FragmentShader API to painting.dart
- Add a SPIR-V FragmentShader interface in painting.dart
- Create end to end pixel tests for ops supported by the SPIR-V to SkSL transpiler
- The end to end tests also test the c++ fragment shader implementation
Co-authored-by: Christopher Crawford <chriscraws@gmail.com>
