Many parts of the floating cursor selection feature is pretty tricky. Some took me a while to figure out. So I added some comments to explain a bit for future readers.
*List which issues are fixed by this PR. You must list at least one issue.*
https://github.com/flutter/flutter/issues/30476
*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 method lived on RenderObjectElement because traditionally, it would be the only one that had to deal with multiple children. The method itself has nothing RenderObjectElement specific, though, and can also be used by any other Element subclass that has multiple children. We are introducing one of those in the near future to handle multiple top-level views.
This is a straight up copy&paste move, no changes have been applied to the code itself.
This PR adds uses of the `--target-os` command line argument when
building kernel sources for precompiled applications for supported
target operating systems. The Dart CFE then:
* treats `Platform.operatingSystem` as if it were defined as the
constant string provided as an argument to the flag,
* treats `Platform.pathSeparator` as the appropriate separator for that
operating system,
* attempts to constant evaluate the initializer for any field annotated
with the `vm:platform-const` pragma, and
* attempts to constant evaluate all calls to a method annotated with the
`vm:platform-const` pragma.
The `vm:platform-const` pragma can appear in either library or user
code. If the attempt to constant evaluate the field initializer or
method call fails, then an error is thrown at kernel compilation time.
Addresses #14233.
The tests in
`packages/flutter_tools/test/general.shard/build_system/targets/common_test.dart`
have been adjusted properly to account for the new passed command line
arguments.
fixes https://github.com/flutter/flutter/issues/120408
Added two gradle tasks, one for grabing the application id, one for grabbing app link domains.
Added a new vmservices to call these two gradle tasks and return the result.
The expected work flow is that the devtool will first call a vmservices to grab all avaliable build variants. It will then choose one of the build variant and call this new services to get application id and app link domains.
Roll to engine to 4f4486b00be28183b482bbb74bbed25f4db153fe pick up dart to 3.1.0-169.0.dev.
Changes since last roll
```
4f4486b00b Roll dart to 3.1.0-169.0.dev (#42602)
```
Manual roll since rolling to dart 3.1.0-169.0.dev requires patching to expression evaluation in flutter tools
Just now I see some good news: https://www.reddit.com/r/FlutterDev/comments/13vo5a2/the_most_important_flutter_310_feature_that/ (ignore the title though...). It was a performance problem in the old days, so it was great that the problem disappears. However, it seems that the doc is not updated yet, so everyone reading MediaQuery page will still use the old way. Thus I create this super-tiny PR :)
Reverts flutter/flutter#128095
We have a tree closure related to the `widget_inspector_test.dart`. I'd
like to see if reverting this resolves the issue.
Closes https://github.com/flutter/flutter/issues/106416.
This PR adds a new `flutter config` setting named `jdk-dir`. When set, the tool will use the JDK found at this location for all Java-dependent tool operations such as building Android apps via gradle and running Android SDK tools.
Fixes https://github.com/flutter/flutter/issues/127090.
https://github.com/flutter/flutter/pull/122505 did a few things to speed up the first asset load that a flutter app performs. One of those things was to not include the main asset in its own list of variants in the asset manifest. The idea was that we know that the main asset always exists, so including it in its list of variants is a waste of storage space and loading time (even if the cost was tiny).
However, the assumption that the main asset always exists is wrong. From [Declaring resolution-aware image assets](https://docs.flutter.dev/ui/assets-and-images#resolution-aware), which predates https://github.com/flutter/flutter/pull/122505:
> Each entry in the asset section of the pubspec.yaml should correspond to a real file, with the exception of the main asset entry. If the main asset entry doesnât correspond to a real file, then the asset with the lowest resolution is used as the fallback for devices with device pixel ratios below that resolution. The entry should still be included in the pubspec.yaml manifest, however.
For example, it's valid to declare `assets/image.png` as an asset even if only `assets/3x/image.png` exists on disk.
This fix restores older behavior of including a main asset as a variant of itself in the manifest if it exists.
This fix also includes a non-user-visible behavior change:
* `"dpr"` is no longer a required field in the asset manifest's underlying structure. For the main asset entry, we do not include `"dpr"`. It makes less sense for the tool to decide what the default target dpr for an image should be. This should be left to the framework.
This PR updates the docs for Transform.Scale constructor by clearing up some ambiguity regarding how the scaling factor is affected by the omission of a value given you provide scaleX and scaleY as arguments as opposed to just scale
addresses bug [126822](https://github.com/flutter/flutter/issues/126822)
- [X ] I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
- [X ] I read the [Tree Hygiene] wiki page, which explains my responsibilities.
- [ X] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement].
- [X ] I signed the [CLA].
- [X ] I listed at least one issue that this PR fixes in the description above.
- [ X] I updated/added relevant documentation (doc comments with `///`).
- [ X] I added new tests to check the change I am making, or this PR is [test-exempt].
- [X ] All existing and new tests are passing.
... found when looking at leak tracker today.
By the way, shall we add some kind of automatic link linter, which goes through all links and see whether they are alive?
Close https://github.com/flutter/flutter/issues/126303
When I encounter bugs in production environment saying null pointer error on `return _size!`, I wish I could know more information! However, currently the information is revealed by `assert(hasSize, 'RenderBox was not laid out: $this');`, thus *only* in debug mode can I know what is `this` (and/or more information that can be added), while in release mode I can only see a stack trace saying it is `RenderBox.size` that throws - nothing more :/
Therefore, it is intuitive to add this extra information in release mode. However, will it affect performance? We all know this is in critical path and should be quite careful. Thus I did some experiments: https://godbolt.org/z/zPPPf5969 From my naive understanding of assembly, the two versions of code (`size!` vs `size ?? throw`) has the same assembly, except that they throw different types of errors. In other words, when there is no error, both code should be equivalent; when there is an error, surely the new code will be slower since it calls `this.toString()`, but the error handling process is rare and already heavy, so this is not a problem.
The old Draggable video had a mistake in it, we've since uploaded a newer version that's been corrected. Thanks for catching that @gspencergoog!
- [na] I read the [Tree Hygiene] wiki page, which explains my responsibilities.
- [na] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement].
- [na] I listed at least one issue that this PR fixes in the description above.
- [na] I added new tests to check the change I am making, or this PR is [test-exempt].
- [na] All existing and new tests are passing.
Fixes#127076
Sometimes a `Selectable`s rect may contain another `Selectable`s rect within it. In the case of `handleSelectWord` when choosing which `Selectable` to dispatch the `SelectionEvent` to, the event would be dispatched to the wrong `Selectable` causing an assertion error to be thrown.
<img width="577" alt="Screenshot 2023-05-24 at 2 46 13 AM" src="https://github.com/flutter/flutter/assets/948037/bb246966-acad-4d81-bd87-758c3ea6ea39">
In the picture above the red outline shows the rect of a two-line piece of text. And the blue rect shows the rect of a piece of text that is on the second line of the two-line piece of text, but has been separated into its own rect for some case, for example when `TextSpan`s are separated by a `WidgetSpan`.
We should check if the text layout of the selectable that has been dispatched the SelectionEvent contains the word, if not then return `SelectionResult.next`, and continue to look through the list of selectables.
Always pass the space code point (`0x20`) to the font subsetter when targetting web because the web engine relies on that character to calculate a font's height.
Fixes#127270
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.
