The members which are currently hidden may get removed from `package:test_api` because they have no uses.
https://github.com/dart-lang/test/pull/2030
Switch to a `show` and list all the exported APIs. This is currently a no-op change, and is forward compatible with the breaking change when it lands.
A `show` is also safer than a `hide` when exporting across package boundaries. Adding a new member to a library _can be_ breaking, but is often treated as non-breaking. If a new member is added to `package:test_api/scaffolding.dart` it will need to be manually added to the list to be usable from `package:flutter_test`, but we anyways want to add a CHANGELOG entry for user facing changes.
- Use `Uri.parse()` to extract pathname.
- Remove unused code from `utils.dart`.
- Add test for URL encoding.
(need to wait for https://github.com/flutter/flutter/pull/126851 to make it into Google3)
The deprecated `[RawScrollbar/Scrollbar/CupertinoScrollbar/ScrollbarThemeData].isAlwaysShown` has expired and is removed in thi PR.
Also, `Scrollbar.hoverThickness` is also removed after having expired.
The replacement for `isAlwaysShown` is `thumbVisibility`. This deprecation was introduced in #96957. The name change came from new behaviors like a track that is conditionally visible. Since the original API only referred to the thumb, the name was changed to reflect this intention. This change is supported by dart fix. â
The replacement for `hoverThickness` is `ScrollbarThemeData.thickness`, which is a MaterialStateProperty that allows for the thickness to respond to multiple states including hover. This deprecation was introduced in #97173. This change is not supported by dart fix. ð
Part of https://github.com/flutter/flutter/issues/127042
#### (plus some more docs)
Fixes https://github.com/flutter/flutter/issues/76760
Fixes https://github.com/flutter/flutter/issues/82391
Fixes https://github.com/flutter/flutter/issues/45619Fixes#117316Fixes#110956Fixes#127282Fixes#32563Fixes#46089Fixes#79077
Part of fixing #62833
This fixes (a bunch of) issues that have been reported differently over the years, but all have the same root cause. Sometimes the NestedScrollView would incorrectly calculate whether or not there is enough content to allow scrolling. This would only apply to drag scrolling (not mouse wheel scrolling for example). This did not relate to how the extent of the NestedScrollView is computed, but just the logic that enabled the actual drag gestures. This fixes that. :)
This workaround was created 6 years ago with no links to bug databases to track. As best we can determine, the issue is no longer present in SkPicture or DisplayList and is most likely obsolete. More importantly, though, non-rendering primitives are ignored by the DisplayList construction and so this workaround will just be ignored anyway. If a problem surfaces about this issue that we haven't discovered by a thorough code search of the current code base, then workarounds should be installed within the relevant implementation modules rather than in the framework (and documented with bugs filed in either or both of Flutter's github repos, and/or the Skia issue database).
Workaround originally created in this PR: https://github.com/flutter/flutter/pull/9654
In the multi view world, `RenderViews` are created by the `View` widget and no longer owned by the binding. Prior to this change, the `LiveTestWidgetsFlutterBinding` owned and managed a special subclass of `RenderView`, the `_LiveTestRenderView`. In the new world, where `RenderView`s can be created anywhere in the widget tree where a `View` widget is used, this setup is no longer feasible. This change removes this special `_LiveTestRenderView` and instead adds debug hocks to `RenderView` to allow the `LiveTestWidgetsFlutterBinding` to draw a debug overlay on top of the content of any `RenderView`.
I come across this when migrating my codebase. There is indeed a linter rule for it: unnecessary_overrides (see screenshot below for an example). I can help enabling the rule (as well as other rules, and/or dart formatter, etc) for Flutter codebase if needed.
Reverts flutter/flutter#126698
There are a bunch of tool crashes on CI that start with this commit. I'm
not sure this PR is the cause because there is no backtrace from the
tool on the crashes. The only error message is `Oops; flutter has exited
unexpectedly: "Null check operator used on a null value`.
Syncs our lints with https://github.com/dart-lang/linter/blob/master/example/all.yaml:
* removed the deprecated `iterable_contains_unrelated_type` and `list_remove_unrelated_type` lints (their replacement `collection_methods_unrelated_type` was already enabled for us)
* enabled the new `no_self_assignments` and fixed one issue triggered by the lint.
Service extensions are unable to handle requests when the isolate they were registered on is paused. The DevTools launcher logic was waiting for some service extension invocations to complete before advertising the already active DevTools instance, but when --start-paused was provided these requests would never complete, preventing users from using DevTools to resume the paused isolate.
Fixes https://github.com/flutter/flutter/issues/126691
Fixes#122081.
When validating an Android Studio installation, add a warning validation message when we are unable to detect the version. This is because we have logic throughout the tool (JDK/JRE-searching) that is at higher risk of failing when we don't know the version.
Fixes#124252, finishing work on the umbrella tracking issue, #126126.
Essentially, after this PR, no (non-test) code should be be referencing/invoking the java home or binary paths.
## Description
This fixes the parsing of `AppLifecycleState` in the services binding so that it knows what it is.
## Related Issues
- Fixes https://github.com/flutter/flutter/issues/127974
## Tests
- Added a test that causes parsing of all the different app lifecycle states.
This fixes an issue where the bottom sheet would rebuild when `enableDrag` is set to true on every tap. This is because `DragGestureRecognizer` would win the arena by default and dispatch the `drag` callbacks (in `acceptGesture`) even though it had not met the drag threshold. This changes keep the default behavior of `DragGestureRecognizer` the same, but adds a parameter `onlyAcceptDragOnThreshold` that a user can use to stop drag callbacks from being fired when the drag threshold has not been met.
Fixes#126833
