- `FlutterViewEmbedder` doesn't create the DOM tree anymore (instead, `DomManager` does).
- `DomManager` only creates the DOM tree (with styles) but doesn't insert it into the document.
- `EngineFlutterView` takes the root element from `DomManager` and inserts it into the document.
- We finally can now create multiple Flutter views, each with its own DOM tree.
cc @yjbanov since I'm making a few changes that probably conflict with your semantics changes.
Part of https://github.com/flutter/flutter/issues/134443
Part of https://github.com/flutter/flutter/issues/137447
The current way we are doing global styles (using `CSSStyleSheet`) forces us to insert the DOM element into the document before we attach any styles to the element. That restriction goes away if we append the styles as `TextNode`s into the `<style>` element.
Now with the movement towards `DomManager`, I would like to be able to create the entire DOM tree of the Flutter View (including all styles) before we insert it into the document.
Part of https://github.com/flutter/flutter/issues/134443
Reverts flutter/engine#48000
Initiated by: jonahwilliams
This change reverts the following previous change:
Original Description:
I just ... deleted `text_box.h` as it appears unused and unreferenced?
---
Work towards https://github.com/flutter/flutter/issues/134969.
All changes were made automatically (i.e. with `--fix`).
I just ... deleted `text_box.h` as it appears unused and unreferenced?
---
Work towards https://github.com/flutter/flutter/issues/134969.
All changes were made automatically (i.e. with `--fix`).
Run the JS unit tests with flutter.js.
I am going to leave the dart2wasm tests doing the old `window.flutterConfiguration` setup for now, until I actually get dart2wasm/dart2js switching logic built into flutter.js itself.
- An explicit API for initializing the implicit view (aka `window`).
- The explicit API is being called during the engine initialization for now, but we could simply remove that or make it conditional.
- Remove direct usages of `window` in tests:
- Most of the usages were being delegated to `PlatformDispatcher` anyway (e.g. `sendPlatformMessage`).
- This makes it **_clearer_** which tests depend on the implicit view (there are still hidden/indirect dependencies though).
Part of https://github.com/flutter/flutter/issues/134443
This PR cleans up a big source of complexity in our pointer handling code. It also drops support for Safari versions prior to 13 ([caniuse](https://caniuse.com/mdn-api_pointerevent)).
Right now, we throw a hard error when running in a browser that doesn't support `PointerEvent`s. Should we turn it into a soft warning, and just disable gesture/pointer handling on those browsers?
For users who need to support older versions of Safari, they can try this polyfill: https://github.com/wessberg/pointer-events (thanks @ditman!)
Fixes https://github.com/flutter/flutter/issues/116141
In order to fix Safari autofill, we've had to give inactive elements non-zero size because Safari does not respect offscreen or 0-sized inputs, and this leads to broken autofill behavior (see: https://github.com/flutter/engine/pull/43058).
As part of these changes, we needed to disable pointer events for the parent `<form>` element so that we don't have pointer event collisions if users hover over or click into the invisible autofill elements within that form.
This led to an issue where offsets weren't being calculated correctly for "active" inputs because they relied on pointer events bubbling up and being caught by the form. The fix is to explicitly set pointer events on the active inputs, so that we can correctly discern when our pointer event target is actually the input and correctly calculate the offsets.
Fixes https://github.com/flutter/flutter/issues/136006
- Move default style values from `FlutterViewEmbedder` to `StyleManager`.
- Move DOM tag names from `FlutterViewEmbedder` to `DomManager`.
- Deduplicate style sheet creation code and put it in `StyleManager`.
Part of Part of https://github.com/flutter/flutter/issues/134443
JS types are going to become extension types and as such, @staticInterop
types cannot implement these types. When we migrate these classes to
extension types, we can add back the subtyping.
Enables https://github.com/dart-lang/sdk/issues/52687.
- Remove a11y announcements from `FlutterViewEmbedder`.
- Simplify a11y announcements tests so they don't need `FlutterViewEmbedder` nor `DomManager`.
- Left a few a11y-multi-view TODOs (cc @yjbanov).
Part of https://github.com/flutter/flutter/issues/134443
Reverts flutter/engine#47825
Initiated by: zanderso
This change reverts the following previous change:
Original Description:
Looks like this was proactively added in https://github.com/flutter/engine/pull/20496, but never wired up to anything on any platform. It is also unused in framework and customer code; we never exposed this on e.g. MediaQuery.
Related framework PR: https://github.com/flutter/flutter/pull/138103 (Checks will fail until that PR is submitted).
- Provide a non-singleton implementation of `EngineFlutterView`.
- Move all common "view" logic into `EngineFlutterView`.
- Remove the unused `windowConfigurations` map from `EnginePlatformDispatcher`.
This relands https://github.com/flutter/engine/pull/43620 with a fix for nested tappable nodes. The first PR introduced this regression: https://github.com/flutter/flutter/issues/134842.
This PR includes the original PR and a fix for the regression. The fix is to call `stopPropagation` on the "click" event so that it is not handled by the ancestor if the child has already decided to send a `SemanticsAction.tap` to the framework. This ensures that there cannot be more than one `SemanticsAction.tap` sent to the framework.
Fixes https://github.com/flutter/flutter/issues/134842
The new `BUILD.gn` files in the Engine tree can't go under
`build/secondary` because Skia still has its own, and they'd be selected
first. So, this PR puts the new `BUILD.gn` files under `flutter/skia`.
## Description
Before we deprecate the `RawKeyEvent` code, it needs to provide parity in functionality. One thing that is missing is the `eventSource` field from the `RawKeyEventDataAndroid` class, which provides the device type for the event.
See https://developer.android.com/reference/android/view/InputDevice#SOURCE_KEYBOARD for an example.
This PR implements that support, and sets the source to `KeyEventDeviceType.keyboard` for platforms that don't provide this information. The main thing it does is add the enum `KeyEventDeviceType`, and a new field `KeyData.deviceType`.
## Related Issues
- https://github.com/flutter/flutter/issues/136419
## Tests
- Updated tests to also read/write/verify this property.
The Dart code has the following declaration:
```dart
@Native<Void Function(Pointer<Void>, Handle)>(symbol: 'PictureRecorder::endRecording')
external void _endRecording(_NativePicture outPicture);
```
=> Dart doesn't expect to get a return value, so C++ shouldn't return
anything.
* Roll esbuild as a CIPD package along with the browser roller. I renamed `browser_lock`/`browser_roller` etc to `package_lock` and `package_roller` since it will handle more than just browsers now.
* Download the esbuild CIPD package via DEPS.
* Have a build rule for running esbuild on some JavaScript or TypeScript
* Bundle and minify `flutter.js` using esbuild.
* Include in `flutter_web_sdk` the original `flutter.js` source, the minified `flutter.js`, and a sourcemap file to map between thnm.
* Also slightly changed the structure to put the `flutter.js` stuff in `flutter_web_sdk/flutter_js` instead of just at the root level of `flutter_web_sdk`. This should be fine because I haven't merged the change that has the flutter tool consume this yet.
This removes skips for the golden tests in `//testing/dart/canvas_test.dart` and instead passes them up to Skia gold.
Adds a utility class for dealing with Skia gold from these tests, as well as the existing fuzzy identical image comparison for tests that just want to do in memory comparison of images generated from the same test.
Removes the old golden files that were in tree.
Part of https://github.com/flutter/flutter/issues/53784
This will allow us to add tooling to do some bundling/minifying of `flutter.js`, which should make this more scalable/extensible long-term.
Also, this removes a few redundant build rules that produce artifacts that the flutter tool doesn't use anymore.
The PR may seem large, but the main changes are simple:
- Introduce a `DomManager` that aims to take over all DOM responsibilities from `FlutterViewEmbedder`.
- Update all references to `flutterViewEmbedder.*domElement*` to `domManager.*domElement*`.
- Describe the general DOM structure of a Flutter View in a doc comment.
Next steps (in future PRs):
- Move all DOM manipulation methods out of `FlutterViewEmbedder` into `DomManager`.
- Move DOM creation logic out of `FlutterViewEmbedder` into `DomManager`.
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.
