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.
Wide gamut is not supported on the iOS simulator, and the iOS platform's FlutterView.isWideGamutSupported checked for this. However, the ImageDecoder decides whether to enable wide gamut based on the engine's settings, so the flag in the settings needs to be modified for the simulator.
This PR adapts `FlutterThreadSynchronizer` to multi-view.
### Problem
The `FlutterThreadSynchronizer` is a macOS engine class to ensure that, if the current window is resized, nothing will not be presented until the layer tree is drawn with the up-to-date size.
This class is not compatible with multiview. A simple way to realize it is: while the class is owned by `FlutterView`, it blocks the _global_ platform thread and rasterizer thread - there is got to be some problems. Indeed, when I was testing with multiple windows (https://github.com/flutter/engine/pull/40399), the app freezes as soon as I resize a window.
The problem is because Flutter only have one rasterizer thread. When I'm resizing window A, A's synchronizer detects that the size mismatches, so it blocks the rasterizer thread to wait for an updated content with the updated size. However, window B is to be rendered next, and B's size matches and will try to rasterize, and will be blocked due to the blocked rasterizer thread, window A's updated content will never arrive, causing a deadlock.
### Changes
This PR removes the single-view assumption of `FlutterThreadSynchronizer` by making it created by `FlutterEngine` and shared by all `FlutterView`s, and that it prevents rasterization for all views if any view has a mismatched size.
The synchronizer is assigned to the view controller in the `attachToEngine:withId` method (now renamed to `setUpWithEngine:viewId:threadSynchronizer:`.
This PR also adds unit tests for `FlutterThreadSynchronizer`, which didn't have any unit tests at all.
* To achieve this, the `beginResizeForView:` method no longer checks whether is called on the main thread, but whether it's called on the main queue. These are equivalent for the real main queue, since the documentation promises that the main queue always executes on the main thread. However, this change allows substituting the queue with a custom one for unit tests.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Part of an ongoing set of efforts to address https://github.com/flutter/flutter/issues/106448
Move the checkerboard layer unit tests onto the DisplayList version of the paint contexts and fix some bugs in the reusability of the DisplayListBuilder that this migration uncovered.
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 PR refactors `Rasterizer` so that the resubmit information is
returned as a temporary struct instead of stored permanently as class
member. This limits the lifetime of these values and reduces class
members.
Additionally, this benefits the multi-view project: if the rasterizer is
going to store multiple surfaces, what variables should be stored in a
map from view IDs? Should all surfaces have a to-be-submitted record?
The answer is "no", because these information is only temporary.
This PR should not need unit tests since it's only a refactor.
## Pre-launch Checklist
- [ ] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [ ] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [ ] I read and followed the [Flutter Style Guide] and the [C++,
Objective-C, Java style guides].
- [ ] I listed at least one issue that this PR fixes in the description
above.
- [ ] 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 `///`).
- [ ] 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
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.
Resolves https://github.com/flutter/flutter/issues/127013.
Makes mask blurs work for most color source + geometry combinations.
Crucially, this doesn't interfere with the fast paths for solid color
RRect blurs (used for shadows).
I'll be addressing mask blurs for text in a follow-up.
Came across this while working on generic fallbacks for mask blurs. For
the unique_ptr case, we always capture ownership and convert to a
shared_ptr anyhow. For the shared_ptr case, we always need to capture a
copy, and so better to not take a const ref and allow the caller to move
if possible.
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.
Everything in Impeller is theoretically treated as if being drawn to
layers of infinite size. Without this change, there's a coverage leak
that occurs in some filters due to the customizable sampling mode. I
should be able to get rid of this 1 pixel padding by refactoring the way
we do sampling in the filter inputs (we already have most of this
infrastructure in place), but this is a correct, safe, and
not-that-expensive solution for the time being.
