[CP-beta]Send statusBarTouch events via dedicated messages#181670
Conversation
Instead of using fake touch events. Before this patch `FlutterViewController` sends two fake touch events (down and up), at `(0, 0)` to the framework to signal that the status bar is tapped on iOS. The scaffold widget and the cupertino page scaffold widget set up gesture detectors to listen for these fake taps, and scroll the "primary" scrollable container to the top in response. This messaging mechanism is sometimes ambiguous, as the framework may interpret that as a pair of regular pointer tap events (for instance in flutter#177992 the modal barrier claims the tap gesture and as a result the modal barrier is dismissed by the fake touch events). This PR changes that to communicate the status bar tap event via a new system channel, and dispatch the events via `WidgetsBindingObserver`s in the framework. See also flutter#177992 (comment) Fixes flutter#177992, fixes flutter#175606 It appears that UIKit also has access to the coordinates of the touch events to determine which scrollable view(s?) to dispatch the scroll to top event to. ```objc * frame #0: 0x00000001032f6520 UIPlayground.debug.dylib`MyScrollViewController.scrollViewShouldScrollToTop(scrollView=0x0000000106014800) at UIScrollView.swift:13:3 frame flutter#2: 0x00000001867c9300 UIKitCore`-[UIScrollView _scrollToTopIfPossible:] + 316 frame flutter#3: 0x00000001867c9604 UIKitCore`-[UIScrollView _scrollToTopFromTouchAtScreenLocation:resultHandler:] + 40 frame flutter#4: 0x0000000186299bbc UIKitCore`__71-[UIWindow _scrollToTopViewsUnderScreenPointIfNecessary:resultHandler:]_block_invoke.358 + 168 frame flutter#5: 0x000000018629981c UIKitCore`-[UIWindow _scrollToTopViewsUnderScreenPointIfNecessary:resultHandler:] + 1212 frame flutter#6: 0x000000018581ed8c UIKitCore`-[UIStatusBarManager _handleScrollToTopAtXPosition:] + 192 frame flutter#7: 0x000000018581eb60 UIKitCore`-[UIStatusBarManager handleTapAction:] + 60 ``` Unfortunately that information is not available to user application. The iOS accessibility bridge currently does create dummy UIScrollViews for each scrollable in the accessibility tree so may be we can take advantage of that in the future. ## Pre-launch Checklist - [ ] I read the [Contributor Guide] and followed the process outlined there for submitting PRs. - [ ] I read the [Tree Hygiene] wiki page, which explains my responsibilities. - [ ] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement]. - [ ] I signed the [CLA]. - [ ] I listed at least one issue that this PR fixes in the description above. - [ ] I updated/added relevant documentation (doc comments with `///`). - [ ] I added new tests to check the change I am making, or this PR is [test-exempt]. - [ ] I followed the [breaking change policy] and added [Data Driven Fixes] where supported. - [ ] All existing and new tests are passing. If you need help, consider asking for advice on the #hackers-new channel on [Discord]. **Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). Comments from the `gemini-code-assist` bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed. <!-- 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
|
@LongCatIsLooong please fill out the PR description above, afterwards the release team will review this request. |
|
This pull request was opened from and to a release candidate branch. This should only be done as part of the official Flutter release process. If you are attempting to make a regular contribution to the Flutter project, please close this PR and follow the instructions at Tree Hygiene for detailed instructions on contributing to Flutter. Reviewers: Use caution before merging pull requests to release branches. Ensure the proper procedure has been followed. |
There was a problem hiding this comment.
Code Review
This pull request refactors the handling of status bar taps on iOS. The previous implementation, which sent fake touch events, has been replaced with a dedicated FlutterMethodChannel named flutter/status_bar. This change simplifies the native code in FlutterViewController and establishes a cleaner communication mechanism. On the framework side, WidgetsBinding now listens to this new channel and notifies observers. This is then used by Scaffold and CupertinoPageScaffold to implement the scroll-to-top functionality. The associated tests and documentation have been updated accordingly. The changes are well-structured and improve the clarity of the implementation.
engine/src/flutter/shell/platform/darwin/ios/framework/Source/FlutterEngine_Internal.h
Show resolved
Hide resolved
0aafd14
into
flutter:flutter-3.41-candidate.0
This pull request is created by automatic cherry pick workflow
Please fill in the form below, and a flutter domain expert will evaluate this cherry pick request.
Issue Link:
What is the link to the issue this cherry-pick is addressing?
#177992
#175606
Impact Description:
What is the impact (ex. visual jank on Samsung phones, app crash, cannot ship an iOS app)?
Does it impact development (ex. flutter doctor crashes when Android Studio is installed),
or the shipping of production apps (the app crashes on launch).
This information is for domain experts and release engineers to understand the consequences of saying yes or no to the cherry pick.
The issues listed above impact app users. For instance #177992 prevents the user from interacting with hamburger menus on iPadOS 26.1+ for context, this probably has always been an issue but on iPadOS 26.1 the height of the status bar became taller so it gets in the way of the hamburger menu.
Changelog Description:
Explain this cherry pick:
See best practices for examples.
[flutter/177992] on iPadOS 26.1, tapping on the status bar dismisses the current modal route.
Workaround:
Is there a workaround for this issue?
Yes. There is a relatively reliable workaround described here: #175606 (comment)
Risk:
What is the risk level of this cherry-pick?
Test Coverage:
Are you confident that your fix is well-tested by automated tests?
Validation Steps:
What are the steps to validate that this fix works?
Following the repro steps in #177992. I've tried the fix myself on master following the steps outlined in the issue and couldn't reproduce the issue.