Fixes https://github.com/flutter/flutter/issues/145618
The local file comparator was being used in post submit for the Linux coverage shard. This corrects it to choose the skipping comparator.
Fixes https://github.com/flutter/flutter/issues/144982
For reference, may have to do with #138442 when we reworked the gesture handling. The adjustments to the comments here were certainly from #138442 not updating them. Confused myself for a minute or two. ð
This pull request refactors if-statements into switch expressions, as part of the effort to solve issue #144903.
Making changes beyond just swapping syntax is more difficult (and also more difficult to review, I apologize), but much more satisfying too.
`@visibleForOverriding` + `@protected` unfortunately does not catch the case where a `compute*` method was overridden in a subtype and the overide was called in that same type's implementation.
I did not add a `flutter_ignore` for this because it doesn't seem there will be false positives.
## Description
This adds some "See also" links to some docs for `TweenAnimationBuilder` and `ValueListenableBuilder`.
Also, moved a "snippet" example in `ValueListenableBuilder` into the examples directory as a Dartpad example.
## Tests
- Added test for the example.
There are two issues in the previous implementation:
1. `_populateDevices` will return the devices from `deviceNotifier` if it had been initialized, assuming that once it's initialized, it has been properly populated. That assumption is not true because calling getters like `onAdded` would initialize `deviceNotifier` without populating it.
2. `deviceNotifier` instance might be replaced in some cases, causing `onAdded` subscribers to lose any future updates.
To fix (1), this commit added the `isPopulated` field in `deviceNotifier` as a more accurate flag to determine if we need to populate it.
To fix (2), this commit made `deviceNotifier` a final member in `PolingDeviceDiscovery`.
* Adds support for `flutter test --wasm`.
* The test compilation flow is a bit different now, so that it supports compilers other than DDC. Specifically, when we run a set of unit tests, we generate a "switchboard" main function that imports each unit test and runs the main function for a specific one based off of a value set by the JS bootstrapping code. This way, there is one compile step and the same compile output is invoked for each unit test file.
* Also, removes all references to `dart:html` from flutter/flutter.
* Adds CI steps for running the framework unit tests with dart2wasm+skwasm
* These steps are marked as `bringup: true`, so we don't know what kind of failures they will result in. Any failures they have will not block the tree at all yet while we're still in `bringup: true`. Once this PR is merged, I plan on looking at any failures and either fixing them or disabling them so we can get these CI steps running on presubmit.
This fixes https://github.com/flutter/flutter/issues/126692
This pull request introduces a new field named `helper` to the InputDecoration class. This field allows for specifying a widget containing contextual information about the InputDecorator.child's value. Unlike `helperText`, which accepts a plain string, `helper` supports widgets, enabling functionalities like tappable links for further explanation. This change aligns with the established pattern of `error`, `label`, `prefix`, and `suffix`.
fixes [#145163](https://github.com/flutter/flutter/issues/145163)
Pre work for https://github.com/flutter/engine/pull/51229. Removes a lot of code referencing v1 of the android embedding, though not necessarily all of it (I may have missed some, it is hard to know).
Will hopefully make landing that PR less painful (or maybe painless?)
A ProxiedDevice has two port forwarder, one to forward remote host port and another to forward remote device port. During an attach workflow, the port was forwarded by the latter. Update ProxiedDDS to make sure that it works in such case.
Fixes#138270.
Moves the majority of the logic of MaterialStateProperties down to the widgets layer, then has the existing Material classes pull from the widgets versions.
## Description
The PR updates `SingleActivator` in order to add a parameter for specifying that a shortcut depends on <kbd>NumLock</kbd> key state.
Somewhat similarly to what is possible with common modifiers expect that a boolean is not enough in this case because: by default, a shortcut should ignore the <kbd>NumLock</kbd> state and it should be possible to define shortcuts that require <kbd>NumLock</kbd> to be locked and other that require it to be unlocked.
@gspencergoog I considered defining a new `ShortcutActivator` implementation for this, but I thinks that adding the feature directly to `SingleActivator` results in a cleaner API.
## Related Issue
Fixes https://github.com/flutter/flutter/issues/145144
Preparation for https://github.com/flutter/flutter/issues/144936
## Tests
Adds 3 tests.
This manually rolls pub packages and updates some calls to use updated APIs that use `Uri` instead of file paths (since macro-generated sources don't exist as files on disk).
Use a dedicated `TextPainter` for intrinsic size calculation in `RenderEditable` and `RenderParagraph`.
This is an implementation detail so the change should be covered by existing tests. Performance wise this shouldn't be significantly slower since SkParagraph [caches the result of slower operations across different paragraphs](9c62e7b382/modules/skparagraph/src/ParagraphCache.cpp (L254-L272)). Existing benchmarks should be able to catch potential regressions (??).
The reason for making this change is to make sure that intrinsic size computations don't destroy text layout artifacts, so I can expose the text layout as a stream of immutable `TextLayout` objects, to signify other render objects that text-layout-dependent-cache (such as caches for `getBoxesForRange` which can be relatively slow to compute) should be invalidated and `markNeedsPaint` needs to be called if the painting logic depended on text layout.
Without this change, the intrinsics/dry layout calculations will add additional events to the text layout stream, which violates the "dry"/non-destructive contract.
This reverts commit 726e5d28c0.
*Replace this paragraph with a description of what this PR is changing or adding, and why. Consider including before/after screenshots.*
*List which issues are fixed by this PR. You must list at least one issue. An issue is not required if the PR fixes something trivial like a typo.*
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
This pull request is part of the effort to solve issue #144903.
In the past, my efforts to reduce line length involved refactoring away from switch statements, but unlike [yesterday's PR](https://github.com/flutter/flutter/pull/144905), this one is full of switch statements that make things more concise!
When a Sliver with items is outside of the Viewport, but within the Viewport's `cacheExtent`, the framework should create SemanticNodes for the items even though they are out of view. However, for this to work, the Sliver's geometry must have a `cacheExtent` (how much space the sliver took up of the Viewport's `cacheExtent`) greater than 0, otherwise it is [excluded](f01ce9f4cb/packages/flutter/lib/src/rendering/viewport.dart (L311-L315)).
`SliverFillRemaining` widgets that fall outside the viewport did not have this set and therefore were being excluded when SemanticNodes were created, even if they were within the Viewport's `cacheExtent`. This PR sets the `cacheExtent` for `SliverFillRemaining` widgets.
In addition, `RenderSliverFillRemainingWithScrollable` would get dropped from the semantic tree because it's child had a size of 0 when outside the remaining paint extent. To fix, we give the child a `maxExtent` of the sliver's `cacheExtent` if it's outside the remaining paint extent but within the viewport's cacheExtent.
Fixes https://github.com/flutter/flutter/issues/142065.
Definitions:
* `RenderViewport.cacheExtent`:
```dart
/// The viewport has an area before and after the visible area to cache items
/// that are about to become visible when the user scrolls.
///
/// Items that fall in this cache area are laid out even though they are not
/// (yet) visible on screen. The [cacheExtent] describes how many pixels
/// the cache area extends before the leading edge and after the trailing edge
/// of the viewport.
///
/// The total extent, which the viewport will try to cover with children, is
/// [cacheExtent] before the leading edge + extent of the main axis +
/// [cacheExtent] after the trailing edge.
///
/// The cache area is also used to implement implicit accessibility scrolling
/// on iOS: When the accessibility focus moves from an item in the visible
/// viewport to an invisible item in the cache area, the framework will bring
/// that item into view with an (implicit) scroll action.
```
* `SliverGeometry.cacheExtent`:
```dart
/// How many pixels the sliver has consumed in the
/// [SliverConstraints.remainingCacheExtent].
```
* `SliverContraints.remainingCacheExtent`:
```dart
/// Describes how much content the sliver should provide starting from the
/// [cacheOrigin].
///
/// Not all content in the [remainingCacheExtent] will be visible as some
/// of it might fall into the cache area of the viewport.
///
/// Each sliver should start laying out content at the [cacheOrigin] and
/// try to provide as much content as the [remainingCacheExtent] allows.
```
Fixes#38926
This patch implements the iOS behavior pointed out by @dkwingsmt at #38926 , which is also consistent with the performance of my settings application on the iPhone.
### iOS behavior (horizontal or vertical drag)
## Algorithm
When dragging: delta(combined) = max(i of n that are positive) delta(i) - max(i of n that are negative) delta(i)
It means that, if two fingers are moving +50 and +10 respectively, it will move +50; if they're moving at +50 and -10 respectively, it will move +40.
~~TODO~~
~~Write some test cases~~