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
Add `SemanticsAction.focus`. This PR just adds the new enum value without any logic. Adding the enum value first to unblock work that needs to be done on both the engine and framework side that will actually implement all the necessary logic.
This is PR 1 out of ~3 for https://github.com/flutter/flutter/issues/83809
Introduces a sentinel value `kTextHeightNone` for `ui.TextStyle.height` which can be used to "unset" the current `TextStyle.height` (and for consistency, it applies to `StructStyle.height` and `ParagraphStyle.height` too). Documentation of `TextStyle.height` can be found [here](https://main-api.flutter.dev/flutter/painting/TextStyle/height.html) (the one from `painting` library not `dart:ui`).
part of https://github.com/flutter/flutter/issues/58765: currently `TextStyle.height` uses `null` as the sentinel value for "no height multiplier specified, use the font height", which has conflicting semantics: it means the height multiplier is not set (so the span height is determined by font metrics) but in reality it also means the height should inherit from its parent span (or in `copyWith` context, it means do not override the height).
The new sentinel value `kTextHeightNone` is currently set to `0.0`. This is because skparagraph internally uses 0 for "no height multiplier", so using 0 should minimize the behavior change:
62f369c759/modules/skparagraph/src/Run.cpp (L65-L67)
This MAY still change the current behavior: for consistency setting `StructStyle.height` / `ParagraphStyle.height` to the sentinel value also unsets the height multiplier which may not be the current behavior.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Previously, when the number of display canvases exceeded the maximum amount, we would augment the rendering to reduce the number of canvases to the maximum amount, and move the pictures from the deleted canvases to the last canvas. However, this would cause ugly rendering in cases where pictures would render on top of the platform views they were supposed to be underneath.
This is especially noticeable when reproducing this bug: https://github.com/flutter/flutter/issues/144854
This changes things slightly so that the pictures are moved to the second-to-last remaining canvas, so that platform views always render over the pictures they are supposed to.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
This PR adds the "Noto Serif Tibetan" fallback font to Flutter Web, so it can render Dzongkha, and other languages in Tibetan script.
(In order to add this fallback font, an automated script is run which updates the versions and glyphs of other fallback fonts at the same time)
(Bundle uploaded to CIPD)
## Issues
* Fixes https://github.com/flutter/flutter/issues/148797
## Testing
* Added unit test for font resolution with sample text
* Manually, in localhost, using the sample Dzongkha test from the Noto site:
<img width="959" alt="Screenshot 2024-05-21 at 2 01 19â¯PM" src="https://github.com/flutter/engine/assets/1255594/3f2db34d-c004-4b90-9fda-62a9cff817f9">
```
à½à½ºà¼à½¡à½à¼ འà½à½à¼à½à¾³à½²à½à¼à½à½à¼à½à½²à¼à½à½²à¼à½à½à½ºà¼à½à½à¼à½à¾²à½à¼à½à¾²à½²à½à½¦à¼ à½à½ºà¼à½£à½¦à¼à½à½£à¼à½à½à½à¼à½à½´à¼à½à½²à¼à½à½à½²à¼à½ à½à¾±à½à¼à½à½à½¼à¼à½à½¼à¼à½à½ºà¼
```
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Reverts: flutter/engine#52885
Initiated by: cbracken
Reason for reverting: while this patch worked fine, it pushed the mac build bot over its time limit. Previous builds were just squeaking under the wire but seeing timeouts on the mac_host_engine host_release shard after this commit. e.g. https://ci.chromium.org/ui/p/flutter/builders/prod/Mac%20mac_host_engine/10667/overview
Looking at ci.yaml I see the timeout is set to 240, but the timeout on the failing shard is c
Original PR Author: cbracken
Reviewed By: {jmagman}
This change reverts the following previous change:
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
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
Reverts: flutter/engine#52859
Initiated by: zanderso
Reason for reverting: This sort of change *is* in scope for a discussion at the Dash forum.
Original PR Author: matanlurey
Reviewed By: {cbracken, gaaclarke, johnmccutchan}
This change reverts the following previous change:
Based on the (internal) discussion around converging on using the official Dart style guide, 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.
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).
Based on the (internal) discussion around converging on using the official Dart style guide, 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.
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).
The size of the LTO build of the engine with the dylib compressed is as follows:
```sh
$ du -k libFlutter*
5236 libFlutter.dylib.tar.gz
4324 libFlutterSlimpeller.dylib.tar.gz
```
Sizes are in KiB. This represents a binary size reduction of 17.41% of the compressed artifacts. The compression ratios will likely differ based on the compression scheme.
Uncompressed, the sizes are:
```sh
$ du -k libFlutter*
16920 libFlutter.dylib
14044 libFlutterSlimpeller.dylib
```
This represents a binary size reduction of 16.99% which is in the same ballpark.
The really mucky bit was backing out the raster cache and persistent cache. I want to clean that up in a later patch so that those TUs are part of a separate submodule.
Opting out of Impeller will lead to a fatal log at startup saying the opt-out is disallowed.
Fixes https://github.com/flutter/flutter/issues/126606
This PR changes from using a different GN pool for each non-compiler tool, to using one GN pool for everything.
Additionally, since we are no longer linking remotely in any configuration, this PR uses the pool for linking.
ObjC and impellerc tasks also do not (yet) run on RBE, so they are also now governed by the pool.
Needs https://github.com/flutter/buildroot/pull/856
Work towards part of https://github.com/flutter/flutter/issues/138798
Allow updating single glyphs in the glyph atlas, without replacing the entire bitmap. Required to efficiently append/update to large atlases.
Due to https://g-issues.chromium.org/issues/40875151?pli=1&authuser=0
and a lack of an ARIA role for plain text nodes (after the removal of
`role="text"` in WebKit recently), there is no way to customize the size
of the screen reader focus ring for a plain text element. The focus ring
always tightly hugs the text itself.
A workaround implemented in this PR is to match the size of the text
exactly to the desired focus ring size. This is done by measuring the
size of the text in the DOM, then scaling it both vertically and
horizontally to match the size requested by the framework for the
corresponding semantics node.
To avoid serious performance penalty, the following optimizations were
included:
- Nodes that are satisfiable by just an `aria-label` do not need this
workaround, and are skipped.
- Nodes that must use DOM text (e.g. links, buttons) but have ARIA roles
that size them based on the element, do not need this workaround, and
are skipped.
- Nodes that do need the workaround are first measured in a single
batch, incurring only one page reflow. Then they are all updated in a
single batch without taking any further DOM measurements. This ensures
that no matter how many text spans are rendered, only one reflow is
needed to measure them all.
- Nodes that need the workaround cache the previous label and size, and
if they do not change, the size is not updated.
Other changes:
- Rename `LeafLabelRepresentation` to `LabelRepresentation`, because
labels also apply to non-leaf nodes (e.g. `aria-label` may be applied to
a container).
- Rename `labelRepresentation` to `preferredLabelRepresentation`,
because a particular label representation cannot be guaranteed. A node
that currently looks like a leaf text node may turn out to be an empty
container, and after adding children to it must switch from using DOM
text to an `aria-label`. Therefore, role manager only specify a
preference, but `LabelAndValue` ultimately decides which representation
is usable.
- Introduce `void initState()` in `PrimaryRoleManager` to be used for
one-time initialization of state and DOM structure after all objects
that are in a one-to-one relationship with each other create all the
references needed to establish that relationship (`PrimaryRoleManager`,
`SemanticsObject`, `element`, `owner`, etc). This is not available at
the time the constructors are called.
Fixes https://github.com/flutter/flutter/issues/146774.
part of https://github.com/flutter/flutter/issues/138798
Works around https://github.com/flutter/flutter/issues/144498 for the glyph atlas.
Adds BlitPass::AddCopy implementation for GLES, which is mostly a copy of Texture::SetContents. Updates the glyph atlas to use a blit pass and device private textures instead of set contents (which is unsafely on Metal).
This also removes DeviceBuffer::AsTexture, which isn't actually used anywhere - and creates a linear texture on iOS (and fails with an unsupported API on simulators).
Note that in general, we don't actually have support for hostVisible textures on GLES _or_ Vulkan. Instead, VMA is falling back to device private textures. We may want to, separately, remove the concept of host visible from textures - and similarly remove the concept of transient from buffers.
This PR moves the core of `browser_detection.dart` to a location in `dart:ui_web` so it can be used by apps and plugins.
In order for the code to be a little bit tidier in ui_web, it's encapsulated in a singleton instance that can be accessed through `BrowserDetection.instance` or a top level global `browser` in `dart:ui_web`.
## Issues
* Needed to fix: https://github.com/flutter/flutter/issues/128943
* Needed to land: https://github.com/flutter/flutter/pull/147346
## Tests
Updated affected tests. Mostly the update was to call the methods from `web_ui.browser.methodName` rather than a global scope. Also split the tests for this module in two files:
* `engine_browser_detect_test.dart` - with the tests specific to the engine (capability detection, etc...)
* `browser_detect_test.dart` - only the tests pertaining to the "core" of the library.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
We don't actually produce mipmaps for any of the textures generated through the `TextureSourceImageGenerator`, even if it is requested of us. So we shouldn't mark the texture as mipmapped in this case. This will allow rendering mechanisms to fall back to a non-mipmapped rendering strategy as needed.
This brings the behavior in line with the CanvasKit renderer, which also uses `None` for the default image shader quality.
I added a few unit tests to cover different filter qualities. It turns out, there is a skia issue that manifests both in CanvasKit and Skwasm when a lazy image is rendered with medium quality. See https://g-issues.skia.org/issues/338095525
