Stop running link hooks in debug mode.
Rationale: link hooks only get access to tree-shaking info in release builds, so they can't do anything meaningful in debug builds. Debug builds should be fast as development cycle, so running less is better.
More details:
* https://github.com/dart-lang/native/issues/1252
Also: rolls packages to latest versions.
## Implementation details
The decision whether linking is enabled is made as follows:
* For normal builds `build_info.dart::BuildMode` is used to determine whether Dart is compiled in JIT or AOT mode.
* Testers always run in JIT, so no linking.
* Native asset dry runs only run for JIT builds (e.g only when hot reload and hot restart are enabled).
## Testing
The integration test is updated to output an asset for linking if `BuildConfig.linkingEnabled` is true, and to output an asset for bundling directly if linking is not enabled.
Brings over the changes from `Switch.adaptive` into `CupertinoSwitch`.
This change adds the following `Switch` parameters to `CupertinoSwitch`:
`inactiveThumbColor,` `activeThumbImage`, `onActiveThumbImageError`, `inactiveThumbImage`, `onInactiveThumbImageError`, `trackOutlineColor`, `trackOutlineWidth`, `thumbIcon`, `mouseCursor`.
The following `Switch` parameters are ignored:
* `activeTrackColor`: because `activeColor` has the same function.
* `inactiveTrackColor`: because `trackColor` has the same function.
* `materialTapTargetSize`: because it is only applicable in `Material`.
* `hoverColor`, `overlayColor`, `splashRadius`: because these parameters configure the radial reaction overlay in `Material`, so are not applicable here.
The following `CupertinoSwitch` parameters which are absent from `Switch.adaptive` are retained:
* `onLabelColor`,
* `offLabelColor`,
* `applyTheme`
`trackColor` and `thumbColor` are of type `WidgetStateProperty` in Material `Switch`, but are currently of type `Color` in `CupertinoSwitch`. For backwards compatibility, both parameters are kept as `Color`s, but can be resolved in different `WidgetState`s using `WidgetStateColor.resolve()`.
This PR does not apply any fidelity updates to `CupertinoSwitch`.
Part of https://github.com/flutter/flutter/issues/149275
Related PRs: https://github.com/flutter/flutter/pull/130425https://github.com/flutter/flutter/pull/148804
These tests aren't actually new, they are old tests that had to be broken out to a new shard in https://github.com/flutter/flutter/pull/151433/. So they've already been passing for some time, and are still passing on their new shard, so they should be safe to mark as not `bringup:true`.
Reverts: flutter/flutter#151608
Initiated by: zanderso
Reason for reverting: Overeager cleanup of unused device spec.
Original PR Author: zanderso
Reviewed By: {christopherfujino, jonahwilliams}
This change reverts the following previous change:
Next step of https://github.com/flutter/flutter/issues/148085
Fix: Submenu anchor misaligned with child panel in web (Resolved#151081)
- The issue comes from different in calculating the position of the menu in web and mobile.
- The calculation is currently base on function `getPositionForChild()` inside `_MenuLayout` in `menu_anchor.dart`, which base on the `anchorRect`
- The calculation of `anchorRect` is from `upperLeft` and `bottomRight`
- `upperLeft` is result of `localToGlobal()` function, which take the `point` arguments to be the base line. Right now, `point` is refer to `Offset.zero`, but it should not be Offset.zero since we having `densityAdjustment`, which is different between web and mobile
- Change `point` from `Offset.zero` to `Offset(dx, -dy)` should fix the error. Use `dx` instead of `-dx` since `dx` already be recalculated refer to the above comment on `densityAdjustment`.
Before:

After:

Issue: https://github.com/flutter/flutter/issues/151081
These changes allow to override existing native endorsed (federated & inline) plugins with e.g. non-endorsed plugin implementations via direct dependencies as described in the section *Platform implementation selection* in the [design doc](https://docs.google.com/document/d/1LD7QjmzJZLCopUrFAAE98wOUQpjmguyGTN2wd_89Srs).
```yaml
# pubspec.yaml
name: example
dependencies:
my_plugin: ^0.0.1
my_plugin_android_alternative: ^0.0.1
```
Closes#80374, closes#59657
Related: Override Dart plugins (#87991, #79669)
Implement Comparable for the TimeOfDay class as discussed in #139098.
Also implements utility methods as `isBefore`, `isAfter` and `isAtSameTimeAs` for convenience and parity with `DateTime` from the dart sdk.
Update style guide to include anti pattern of mentioning someone in a comment and the flurry of notifications that result.
Came up in a google contributor roundtable discussion.
Multiple fixes related to heading levels:
* Fix heading level absorption. Heading level would get erased when a semantics config is absorbed into another. With this change the highest heading level wins.
* Add `headingLevel` to the diagnostics of `SemanticsNode`.
* Add unit-tests for heading levels.
* Add an a11y use-case for headings.
Improves https://github.com/flutter/flutter/issues/46789 and general accessibility of headings.
Updating the docs to reflect the change in https://github.com/flutter/engine/pull/53278.
`Semantics(identifier: '...')` can now be used on web to facilitate testing and DOM lookup when it comes to semantics nodes.
While exploring https://github.com/flutter/flutter/issues/107607, I noticed that flutter_tools test results change based on whether `dart test` is run from a terminal or from a process (such as a Dart program). I also ran into this while writing tests for https://github.com/flutter/flutter/pull/150667.
This is due to tests that rely on the global `Stdio` instance, on which the `hasTerminal` property depends on whether the tool is being invoked from a terminal.
Ideally, `testUsingContext` would require any tests that depend on `globals.stdio` to define an override for `Stdio`, but this is not the case. Until a solution to this more general problem is figured out, I think we should have `testUsingContext` always provide a `Stdio` override by default.
This PR resolves [some problems I was having with `DataTable`](https://github.com/flutter/flutter/issues/151005), based on advice from the style guide:
> ### Answer your own questions straight away
> If you find yourself asking a question about our systems, please place whatever answer you subsequently discover into the documentation in the same place where you first looked for the answer. That way, the documentation will consist of answers to real questions, where people would look to find them.
The `DataTable` documentation now specifies that the widget is based on the Material 2 spec, and it offers a list of useful alternatives.
<br>
Additionally, an item in the "See also" section was updated to use a reliable Go link:
```diff
- /// * <https://material.io/design/components/data-tables.html>
+ /// * <https://material.io/go/design-data-tables>
```
Documentation was migrated as follows:
1. did a RegEx search for `(///.*)MaterialState` and replaced with `$1WidgetState`
2. made sure that `MaterialStateOutlineInputBorder` & `MaterialStateUnderlineInputBorder` were unaffected
3. removed unused imports
<br>
The following files & directories were excluded:
- examples/
- packages/flutter/test/
- material_state.dart
- material_state_mixin.dart
- widget_state.dart
<br>
I believe this should be very straightforward, but I'd also be happy to break the PR in half to make it easier to review.
(related: #151373)
This is a very common usage of ad so we want to make sure it's performant.
From the video, it scrolls quite smoothly, but we want to see the numbers, and keep monitoring it in case of regression.
https://github.com/flutter/flutter/assets/41930132/c7811c15-ac07-4989-a8a9-3c128e08cbe0
*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.*
Fixes https://github.com/flutter/flutter/issues/150230
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
## Description
This re-enables the `SemanticsAction.focus` matchers so that they actually do something now instead of ignoring the action.
This was so that we could land the focus action changes without causing breakages in customer tests, and now that customer tests have been updated, we can land this PR turning it on again.
## Related Issues
- Fixes https://github.com/flutter/flutter/issues/149842
## Related PRs
- https://github.com/flutter/flutter/pull/149840
## Tests
- Updates semantics tests to actually look for the focus action.
When a user scroll gesture ends, Material Design floating headers snap into place by animating as far as needed and overlaying the underlying scrollable content. For example Gmail's search header works this way. Other apps handle the snap animation by scrolling content out of the way. Instagram for example.
Added `SliverFloatingHeader.snapMode`, whose value can be `FloatingHeaderSnapMode.overlay` (the default) or `FloatingHeaderSnapMode.scroll`, so that developers can choose the snap animation style they want.
| FloatingHeaderSnapMode.overlay | FloatingHeaderSnapMode.scroll |
| --- | --- |
| <video src="https://github.com/flutter/flutter/assets/1377460/05c82ddf-05a6-4431-9b1e-88b901feea68" /> | <video src="https://github.com/flutter/flutter/assets/1377460/fedc34de-0b55-4f0d-976f-2df1965c90bc" /> |