This is a refactor to make `MouseTracker` use the same callback for both kinds of device update. Instead of using two different callbacks for the two device updating methods, `MouseTracker` now receives a hit testing callback at construction, which is the same hit testing method as the one used for other gestures.
This PR not only makes the code cleaner, but also removes the single view assumption from `MouseTracker`, whose code no longer refers to `RendererBinding.renderView`. In the future, we only need to modify `hitTest` (which we will have to do to support gestures for multi-view anyway) to make mouse tracker support multi-view.
*The order of calling Navigator.pop and PopupMenuItem.onTap has been changed so before calling PopupMenuItem onTap method, PopupMenuBotton onSelect method is going to be called.*
*Solves #127443*
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
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.
https://github.com/flutter/flutter/issues/128440
The current version of the action has a bug where the sync-labels default value is not read correctly. Explicitly setting to see if that stops the removals.
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.
## Description
Changes the context menu example for `MenuAnchor` so that it uses right-click, or (on macOS and iOS only) ctrl-left-click, for the context menu. Also disables the browser context menu on web platforms.
## Tests
- Updated test to reflect new triggers.
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.
