## Description
This PR fixes a `DatePicker` flickering issue observed on some devices
with a small display.
### Before
When the date picker input dialog is shown the virtual keyboard opens
and reduces the available height. The current logic reacts by removing
the picker `TextField`. Because there is no more `TextField` the virtual
keyboard is hidden and the available height increases, at that moment
the `TextField` is shown again. Due to autofocus the virtual keyboard
opens which leads to the removal of the `TextField` and so on.
https://github.com/user-attachments/assets/deb70f2e-1c8b-47a9-9db6-47bc521e4eb7
### After
When there is not enough vertical space for the input date picker
dialog, the header is hidden instead of hiding the `TextField`.
https://github.com/user-attachments/assets/14051ee9-3b9a-4467-a4a0-4ee91b4979ea
## Related Issue
[Fixes DatePickerDialog text input causes keyboard to open and close on
a 480p Android
emulator](https://github.com/flutter/flutter/issues/140311).
## Tests
Adds 2 tests.
Closes https://github.com/flutter/flutter/issues/167667.
In this PR:
- `FlutterFeaturesConfig` reads from the global config, current
pubspec.yaml, and environment
- `FeatureFlags` now delegates "was this configured" to
`FlutterFeaturesConfig`
- `featureFlags` (`Context`) now is created with knowledge of the
current `pubpec.yaml`, if any
Once this lands and we play with it a bit (i.e. migrate
`disable-swift-package-manager`), we can publicize it and update website
documentation (it won't make it into this beta/stable release anyway).
I did a significant rewrite of `feature_test`, as lots of what was being
tested no longer made sense.
Notable changes:
* Allows macrobenchmarks to run via `flutter run`.
* Splits macrobenchmarking between "orchestration logic" and "app
serving" (served on separate ports on the same machine to keep the
scheme consistent with the `flutter build` path).
* Adds an intercepted entrypoint for web benchmarks. We can't pass flags
to the app since it's not supported, so I've hard-coded the
orchestration server's port.
* Adding logic to connect to an existing Chrome debugger instance (vs
spawning one) for benchmarks.
Merges iOS and macOS configuration and SDK finder scripts:
* //build/mac/find_sdk.py and //build/ios/config/ios_sdk.py merge to
//build/mac/apple_sdk.py.
* //build/config/ios/ios_sdk.gni and //build/config/mac/mac_sdk.gni
merge to //build/config/apple/apple_sdk.gni. gn args for macOS are
available on all builds with `host_os == "mac"`. gn args for iOS are
available on builds where `is_ios` is true (in place of the existing
conditional import logic). Merging the two allows us to check all
Apple SDK-related variable for anything missing and run `apple_sdk.py`
a maximum of once across all Apple platforms.
* Adds `Platforms` directory to `//flutter/prebuilts`, which contains
Apple platform symlinks for `iPhoneOS`, `iPhoneSimulator`, `MacOSX`.
Adds `ios_device_platform_path`, `ios_simulator_platform_path`,
`mac_platform_path` gn args to hold these paths. Adds logic to
`//flutter/tools/gn` to locate these paths and prepopulate these args
from them to avoid running the script as part of the build.
These are used to link to Swift core libs for each platform where
necessary, as well as (for tests) test frameworks and `.swiftmodule`s
like XCTest.framework.
* Eliminates `Library/Frameworks` symlink from `//flutter/prebuilts`.
This path is a subdirectory of each of the platform directories above.
It was used to populate `platform_frameworks_path` in
`//flutter/shell/platform/darwin/ios/BUILD.gn` using sort of sketchy
relative-path logic.
Further, the existing logic for greating the link was buggy for runs
of `ios_sdk.py` where the `--sdk` option was not specified (i.e. all
runs where `--as-gclient-hook` were specified). Without this option,
we cycle through both `iphoneos` and `iphonesimulator` SDKs, and since
this symlink was written on each iteration through the `SDKs` list, it
was always linked to the `Library/Frameworks` directory for the last
item in the list: `iPhoneSimulator.platform`. The platform arg for the
current build is now resolved to `ios_platform_path` from which we
resolve `$ios_platform_path/Developer/Library/Frameworks`.
A follow-up patch will refactor the iOS build file to extract an iOS
test config that eliminates some of the unnecessary duplication of
cc_flags, swiftflags, and ld_flags across targets.
Issue: https://github.com/flutter/flutter/issues/167592
## Pre-launch Checklist
- [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] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [X] All existing and new tests are passing.
If you need help, consider asking for advice on the #hackers-new channel
on [Discord].
<!-- Links -->
[Contributor Guide]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#overview
[Tree Hygiene]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md
[test-exempt]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#tests
[Flutter Style Guide]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md
[Features we expect every widget to implement]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md#features-we-expect-every-widget-to-implement
[CLA]: https://cla.developers.google.com/
[flutter/tests]: https://github.com/flutter/tests
[breaking change policy]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#handling-breaking-changes
[Discord]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Chat.md
[Data Driven Fixes]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Data-driven-Fixes.md
Previously, mnemonics specified in templates that used compiled_action
and compiled_action_foreach would not be forwarded. This made actions
like ImpellerC invocation unable to tag themselves. As Ninja builds
progressed, only a mysterious ACTION label would be emitted for all
ImpellerC edges. Now, the edges tag themselves.
Fixes `CupertinoDialog` not respecting Directionality for actions
Issue refers to AlertDIalog.adaptive, but I have found that problem
occurs only in `CupertinoDialog`.
## Related Issues
* Fixes [Dialog actions do not respect Directionality
#166880](https://github.com/flutter/flutter/issues/166880)
## Tests
Added 1 test
## Pre-launch Checklist
- [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] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.
## Description
This PR fixes `CarouselView.weigthed` crashes due to given constraints
being zero (which happen, for instance, when viewportDimension is 0.0).
At startup, a warm-up frame can be produced before the Flutter engine
has reported the
initial view metrics. As a result, the first frame can be produced with
a size of zero. In the context of CarouselView this leads to some
problems mainly related to division by zero.
Similar to https://github.com/flutter/flutter/pull/167271 which
addressed the same problem for `CarouselView`.
## Related Issue
Fixes https://github.com/flutter/flutter/issues/167621
## Tests
Adds 3 tests.
Adds a `swift` tool to the gn mac toolchain and wires up support for
Swift `source_set` targets. Ports `FlutterUIPressProxy` to Swift.
`gn` toolchain modifications include:
* Removes `//flutter/third_party/libcxx/include` and
`//flutter/third_party/libcxxabi/include` from the default
`include_dirs` on all `source_set` targets, and instead adds them via
`cflags` and `cflags_cc` so they continue to be picked up by C, C++,
Obj-C, Obj-C++ targets. Flutter's custom libc++ library headers should
be picked up by C, C++, Objective-C, and Objective-C++ targets, but not
Swift targets. Swift code does not use libc++ directly, but many Apple
core libraries such as Foundation.framework are implemented in
Objective-C/Objective-C++ and directly or indirectly rely on Apple's
libc++ implementation in System.framework. Because of this, and because
Swift compiles use Clang modules, we should ensure the correct (Apple)
libc++ is picked up from Swift targets by ensuring our own libc++ is
not.
* Adds a default empty list for `swiftflags` to `source_set` targets.
This list is used by for Swift `source_set` targets by the `swift` tool
in the gn toolchain.
* Adds a `//build/config/ios:compiler` config to
`engine/src/build/config/ios/BUILD.gn`. This sets default `swiftflags`
for iOS targets. This attribute is (only) used by the new `swift` tool
in the toolchain.
* Adds `-g` to `swiftflags` for debug (unopt) builds in
`engine/src/build/config/compiler/BUILD.gn`.
* Adds a `swift` tool to the gn toolchain that invokes `swiftc.py` to
perform compilation and generate a bridging header. This tool is invoked
automatically by gn for Swift `source_set` targets.
* Adds `//build/toolchain/apple/swiftc.py`, a wrapper script around
`swiftc` in Xcode's Swift toolchain. This script ensures builds are
invoked hermetically using a new build cache directory for the emitted
swiftmodule, precompiled header, and bridging header, for each compile.
The outputs are then copied into the gn output directory. Also adds
supporting script `//build/toolchain/apple/get_tool_mtime.py` and data
`//build/toolchain/apple/swift_const_gather_protocols.json`, both used
by `swiftc.py`.
* Adds a `cxx_module` tool to the gn toolchain that supports clang
module-based compiles. This is used for libc++ transitively via
System.framework and others that rely on it.
`gn` variable modifications include:
* Adds `apple_host_toolchain_path` variable in
`engine/src/build/config/apple/apple_sdk.gni`. This is set using
`//build/mac/find_sdk.py` to the path of Xcode's
`XcodeDefault.xctoolchain`. This is where Xcode's `swiftc` tool and some
Swift libraries are located. This will be used to create a symlink in
the `//flutter/prebuilts/SDKs` directory to locate Swift tooling during
builds.
* Updates `enging/src/tools/gn` to pre-populate that path as we do with
other Xcode SDK path symlinks, to improve performance.
* Adds `ios_swift_lib_paths` in
`engine/src/build/config/ios/ios_sdk.gni` which holds the path of Swift
shared libraries for either iOS physical device or simulator targets.
This is within the appropriate `iphone` or `iphonesimulator` SDK
directory within Xcode.
`verify_exported.dart` changes:
* Allow exported symbols that match regexp
`^_\$s\d+InternalFlutterSwift`. To allow Swift symbols to be exported in
an Objective-C bridging header, they must be `public` or `open`. We only
ever use these types internally within the framework and never publish
these types in a public header. Like `_InternalFlutter` Obj-C symbols,
we allow `InternalFlutterSwift` symbols, as they are clearly marked as
internal and an end user would need to reverse engineer out their own
header to use them.
* Allow Obj-C symbols in the `(__DATA,__data)` and
`(__DATA_CONST,__const)` in addition to the existing Mach-O sections, so
long as it matches the existing criteria.
Finally, this patch adds Swift code to the embedder and embedder tests
as proof of concept and to prevent regressions. This ports
`FlutterUIPressProxy` and its subclass `FakeUIPressProxy` to Swift in
order to verify both:
* Objective-C imports of Swift via a bridging header
* Swift imports of Swift via a bridging header
Issue: https://github.com/flutter/flutter/issues/144791
## Pre-launch Checklist
- [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] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [X] All existing and new tests are passing.
If you need help, consider asking for advice on the #hackers-new channel
on [Discord].
<!-- Links -->
[Contributor Guide]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#overview
[Tree Hygiene]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md
[test-exempt]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#tests
[Flutter Style Guide]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md
[Features we expect every widget to implement]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md#features-we-expect-every-widget-to-implement
[CLA]: https://cla.developers.google.com/
[flutter/tests]: https://github.com/flutter/tests
[breaking change policy]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#handling-breaking-changes
[Discord]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Chat.md
[Data Driven Fixes]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Data-driven-Fixes.md
Fixes https://github.com/flutter/flutter/issues/163576
In `updateWith()` method, `_replaceChildren()` is called to generate
`_children` list. `_children` list is used to generate the hit test
order (`childrenInHitTestOrder`).
In `_replaceChildren()`, `childrenIn**Inverse**PaintOrder` is directly
assigned to _children, so _children itself follows hit test order. So
when we generate the `childrenInHitTestOrder`, we don't need to reverse
the children again.
https://github.com/user-attachments/assets/df9d852f-231e-4480-8d8b-10c1d406f120
## Pre-launch Checklist
- [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] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.
The keyboard hot restart test listens to `flutter run` logs and then
does an action. However, the test prints the `flutter run` log after the
action. This results in confusing logs.
For example:
https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8716606099574306145/+/u/run_keyboard_hot_restart_ios/stdout
```
═══════════╡ ••• Launch app and wait for keyboard to be visible ••• ╞═══════════
...
stdout: Installing and launching... 37.2s
stdout: Syncing files to device swarming’s iPhone...
════╡ ••• Update the app to no longer force the keyboard to be visible ••• ╞════
════════════════════════╡ ••• Hot restart the app ••• ╞═════════════════════════
════════════╡ ••• Wait until the keyboard is no longer visible ••• ╞════════════
stdout: flutter: Keyboard is open
```
Here, the test waits until the keyboard is visible before moving onto
the test's next step. However, the log that triggers this action
(`flutter: Keyboard is open`) is printed after the action was taken
(`Update the app to no longer force the keyboard to be visible` and
`Wait until the keyboard is no longer visible`). This is confusing.
Follow-up to: https://github.com/flutter/flutter/pull/167013
Part of: https://github.com/flutter/flutter/issues/10713
Fixes#145592.
When slivers in a CustomScrollView overlap, this makes it possible to
control which of the slivers will sit in front of the other one, meaning
that it paints last and gets hit-tested first.
In this version there are two choices: the first sliver paints in front,
or the last sliver paints in front. The first sliver in front is the
default; it's the behavior needed for SliverAppBar, or other situations
where the first sliver is some sort of header.
The existing behavior is actually quite a bit more complicated than
that, with the "center" sliver painting in front, plus it varies
depending on `shrinkWrap`. As far as I can tell this behavior isn't
documented anywhere. It's equivalent to first-sliver-in-front whenever
`CustomScrollView.center` isn't being used; and in fact there don't seem
to be any tests in the tree that notice the difference between the
existing behavior and first-sliver-in-front.
So although I actually have an implementation that preserves the more
complex existing defaults, I'm hopeful we won't need it: if neither
google3 nor customer tests are relying on that undocumented distinction
either, then we can go ahead and simplify this behavior without a
breaking change.
