Even with separate allocators and queues, I think that using the concurrent runner is just overloading the phone.
On Android force it all onto the I/O thread.
https://github.com/flutter/flutter/issues/128919
Safari web autofill has an issue where the autofill dialog flickers and doesn't completely render and allow users to fill any forms.
This is caused by a collision between default browser behavior on the `pointerdown` event and the programatic focusing of our inputs.
### Problem
When we click into an input, the element is created, placed, and (explicitly) focused. However, all of this is done before the `pointerdown` event can finish. Since all `pointerdown` elements target the `flutter-view` (formerly `flt-glass-pane`), default browser behavior is to trigger a `blur` event since the target doesn't match what's currently focused, which is the input element. This doesn't manifest into most text editing issues because we listen for `blur` events on the `input` and call `focus()`. However, in Safari, this near-instant focus/blur results in the disappearance of the autofill popup.
The current chain of events looks like:
`pointerdown` event starts -> input is created + focused -> `pointerdown` event ends, and triggers a `blur` -> input refocuses on `blur`
### Solution
This change ensures that we don't focus the input until after the `pointerdown` event concludes, thus preventing any rapid-fire `blur` event from being emitted. We do this via wrapping the focus logic within a zero-duration Timer.
The new chain of events looks like:
`pointerdown` event starts -> `pointerdown` event ends -> input is created + focused
### Alternative approach
Note: Another option was to call `preventDefault()` on the `pointerdown` event to prevent the `blur` from occurring that way. There may be unintended side effects from that approach, especially as it relates to platform views. The surface area of the chosen approach is much more contained and should result in no side effects outside of Safari Desktop's text editing strategy.
<img width="699" alt="Screenshot 2023-06-15 at 7 34 02 PM" src="https://github.com/flutter/engine/assets/110993981/3548d1ea-65f7-412f-b3c7-f94db2658127">
Fixes https://github.com/flutter/flutter/issues/127960
Moving `webOnlyAssetManager` to `dart:ui_web` and renaming it to simply `assetManager`. This will make it easier for plugins and apps to get a hold of the asset manager without doing `dart:ui` shims or other shenanigans.
Part of https://github.com/flutter/flutter/issues/126831
I was refactoring this class on the Skia side and saw Flutter #included it, but did not appear to actually use it.
This replaces an unnecessary #include with a necessary one.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Work towards https://github.com/flutter/flutter/issues/123468
In order to support the usage of BufferView, I generalized the tracked buffer type from DeviceBuffer to Buffer. Should be mostly safe!
I confirmed that this runs correctly under moltenvk but I'm uncertain if there are additional ways to validate.
The destination buffer format may not exactly match the source format. In particular, the alpha type of the source may need to be converted to the alpha type of the destination.
Fixes https://github.com/flutter/flutter/issues/128102
To make the `HashUrlStrategy` a bit cleaner (at least for the home page), let's get rid of the notorious `/#/` when the app is in the home page.
Non-home pages continue to have a hash in them. After this PR, here are some example URL changes:
- `http://domain.com/#/` => `http://domain.com/`
- `http://domain.com/#/page1` => (remains the same)
This change is backwards compatible, i.e. if you write `http://domain.com/#/` in the address bar, the app will load and open the home page correctly; and flutter will automatically change the URL to `http://domain.com/`.
Fixes https://github.com/flutter/flutter/issues/127608
Make Skwasm consistent with the CanvasKit backend's sampling options in `drawAtlas`. Also, fix the atlas rendering tests so the sprites don't bleed into each other.
1. Wire platform views' `creation params` in the engine.
2. Move acceptable factory signatures to `dart:ui_web`.
3. Don't put any JS types in `dart:ui_web`'s interface.
- Use type casting to check at runtime instead.
4. Tests.
Part of https://github.com/flutter/flutter/issues/127030
In order to make `HtmlElementView` more useful, we need to expose an API for getting the created platform view element. ~~This would allow `HtmlElementView` to set attributes and styles on the element.~~
This would allow us to add a new callback to the `HtmlElementView` that would return the result of calling the registered platformViewFactory to the user, after it's been created and added to the DOM, so the user can do with it as they please.
Required by https://github.com/flutter/flutter/pull/126176
- Moving them to the end prevents the screen reader from landing on them before the relevant content.
- Making them `div`s instead of `label`s prevents some screen readers (ChromeVox in particular) from landing on the live elements when the live elements are empty.
Fixes https://github.com/flutter/flutter/issues/127862.
Reverts flutter/engine#42134
This is blocking the engine into framework roller:
See: https://cirrus-ci.com/task/5610586755563520
```
Analyzing 3 items...
error ⢠The class 'UrlStrategy' can't be extended outside of its library because it's an interface class ⢠dev/integration_tests/web_e2e_tests/test_driver/url_strategy_integration.dart:48:31 ⢠invalid_use_of_type_outside_library
1 issue found. (ran in 321.8s)
ð ð
```
Finally, we can remove this JS global function for customizing the url strategy.
Why I think we don't need to go through an official deprecation process:
1. It was initially made for internal use in Google3, and right now there are no references to it.
2. There's no public documentation of this JS function.
3. External users customize their url strategy through `flutter_web_plugins` which has been [migrated](https://github.com/flutter/flutter/pull/123443) already.
Related to #127701
When landing a seemingly unrelated CL, clang-tidy started failing with:
```
❌ Failures for clang-tidy on /b/s/w/ir/cache/builder/src/flutter/lib/ui/painting/image_generator_apng.cc:
/b/s/w/ir/cache/builder/src/flutter/lib/ui/painting/image_generator_apng.cc:57:10: error: unchecked access to optional value [bugprone-unchecked-optional-access,-warnings-as-errors]
return images_[image_index].frame_info.value();
^
/b/s/w/ir/cache/builder/src/flutter/lib/ui/painting/image_generator_apng.cc:154:13: error: unchecked access to optional value [bugprone-unchecked-optional-access,-warnings-as-errors]
switch (frame.frame_info->blend_mode) {
^
/b/s/w/ir/cache/builder/src/flutter/lib/ui/painting/image_generator_apng.cc:526:7: error: unchecked access to optional value [bugprone-unchecked-optional-access,-warnings-as-errors]
if (images_.back().frame_info->disposal_method ==
^
/b/s/w/ir/cache/builder/src/flutter/lib/ui/painting/image_generator_apng.cc:535:7: error: unchecked access to optional value [bugprone-unchecked-optional-access,-warnings-as-errors]
images_.back().frame_info->disposal_method ==
^
/b/s/w/ir/cache/builder/src/flutter/lib/ui/painting/image_generator_apng.cc:538:5: error: unchecked access to optional value [bugprone-unchecked-optional-access,-warnings-as-errors]
image->frame_info->required_frame = images_.size() - 1;
^
Suppressed 1772 warnings (1772 in non-user code).
```
This addresses those checks by making sure frame_info has a value.
## 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 Hixie said the PR is test-exempt. See [testing the engine]
for instructions on writing and running engine tests.
- [ ] I updated/added relevant documentation (doc comments with `///`).
- [x] I signed the [CLA].
- [ ] 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
[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
## Description
This reverts commit 879917b to re-land #40542 to fix the lint warning which caused the original PR to be reverted (the lint warnings were turned on after the original was landed, which is why it wasn't caught earlier).
Fixes https://github.com/flutter/flutter/issues/126878
This disables device private upload on iOS when backgrounded, and disables mipmap generation when backgrounded.
We don't have a good way to test the core problem in this repo because it only reproduces on physical iOS hardware - simulators don't really care if you do this stuff in the background.
I'll write a devicelab test in the framework to capture this. In the mean time it can be reviewed.
We could consider making the IOManager a shared_ptr instead of having an fml::WeakPtr and that'd clean up some of the extra arguments to engine construction - or we could consider vending the sync switch from impeller::Context unconditionally, but it's pretty iOS specific...
Ordering of input elements inside of the DOM tree for autofill groups does not reflect the order of the form rendered on screen. This is causing some issues with password managers and autofill, specifically Bitwarden.
We are currently always appending the currently focused input element to the end of the form.
This leads to a tree that appears out of order:
<img width="354" alt="Screenshot 2023-05-23 at 2 57 37 PM" src="https://github.com/flutter/engine/assets/110993981/7e90a93f-5522-4482-8fb6-a1607b403d10">
This fix is tracking the position of where the focused input node should be inserted and inserting it there, rather than always at the end of the form. Once the tree is ordered correctly, Bitwarden's autofill logic works in Flutter forms.
Tree order after fix:
<img width="502" alt="Screenshot 2023-05-23 at 6 01 05 PM" src="https://github.com/flutter/engine/assets/110993981/bd15a8a1-71f4-4f28-a86e-1903953bf030">
Fixes https://github.com/flutter/flutter/issues/61301
Previously the Flutter framework had been inflating the rectangle computed for the bounds of a drawShadow operation in order to work around potential inaccuracies in the SkPicture's bounds calculation.
That workaround is now obsolete for most platforms and was removed from the framework (see https://github.com/flutter/flutter/pull/127052). But the Web HTML backend is using different code for computing shadow bounds. This PR restores the workaround for Web HTML for consistency with the old behavior.
Implements `drawVertices`, `drawPoints`, and `drawAtlas`.
These are the last rendering APIs that are unimplemented in Skwasm! (Although we still need to add platform view support).
This implements making images from web browser codecs.
This implements a JS support library as well, which allows both the main thread and the background thread to keep a registry of JS objects that can be referenced by a numeric ID and transferred between each other.
In order to use the exported `PlatformLocation` cross-platform, we need to remove any JS types from the interface. Namely, `DomEventListener`.
Required by https://github.com/flutter/flutter/pull/126851
This also removes the appended divs after a short time so that screen readers don't navigate to it, especially when users are entering the DOM to enable accessiblity.
Fixes https://github.com/flutter/flutter/issues/127335.
I've been slowly hacking on a prototype alongside a doc (public go link [imminent](https://github.com/flutter/website/pull/8716)) for a while (the doc has been changing a lot as a result of prototyping) and I think it's time to start landing parts of this prototype/experiment in-tree.
This initial PR just sets up the main context singleton on the UI thread. After this, I'll land the shader management stuff.
I re-used the existing experimental 3D flag for this, since this is meant to replace what can be done with Impeller Scene anyway.
In this PR, I'm leaving a getter for `platformViewRegistry` in `dart:ui` for backwards compatibility. At some point, we need to properly deprecate it (e.g. print a warning asking users to import it from `dart:ui_web` instead).
Next step is to migrate all call sites in flutter/flutter, flutter/packages and flutter/devtools (anything else?).
Issue: https://github.com/flutter/flutter/issues/126831
Fixes https://github.com/flutter/flutter/issues/41563
