Repository navigation
[CP-beta][iPhone Duo] Use the correct UIScreen to report the display size and update when fold/unfold - #195690
Conversation
…update when fold/unfold (flutter#195199) On iPhone Duo, `UIScreen.mainScreen` always refers to the outer display. The iOS embedder used `UIScreen.mainScreen`, so when the app is on the inner display, `PlatformDispatcher.displays` reports the wrong screen. This PR ensures the embedder to report the correct screen size to the framework, and when switch between inner/outer screens, update the framework with the new size. ## Why still need `UIScreen.mainScreen` fallback The framework can read display information as soon as the isolate launches, before any view is in a window (see this test project flutter#195177 (comment)). At that point we do not know which screen the FlutterVC will be added to (if we ever add it to the screen). MainScreen remains a best-effort initial guess (better than a `.zero` size since flutter developers may have already depend on the value). It is corrected as soon as the view is laid out in a window. `_hasSentDisplays` makes the engine use the `UIScreen.mainScreen` fallback only for the very first display it sends, before any view is in a window. After that, if the view isn't in a window (e.g. a newly attached view controller whose view isn't loaded yet), the engine keeps the last reported display instead of replacing it with the `mainScreen` guess. The flag resets when a new shell is adopted, so each new shell still gets an initial display. ## Why not fallback based on hinge state? 1. Hinge API only works for a view that's already in a window. 2. There's no dedicated API to get the inner display (unless with another deprecated `UIScreen.screens` API which isn't great either). 3. Open state could use both inner and outer displays (accessory scene) ## Why change in `SemanticsObject` is simpler than `FlutterEngine/VC` Because `SemanticsObject` is a "pull" model, where we simply need to check which screen when accessing it. On the other hand, `FlutterEngine/VC` is a "push" model, where we have to make sure to update the value when screen changes. ## Integration test I don't think there's a `simctl` sub-command that allows us to fold/unfold the simulator. We could add a integration test in the future if such api become available. ## Manual test I have manually verified using [this test project](flutter#195177 (comment)), and confirmed the reported value is correct, and updated correctly once fold/unfold Scenario | Window screen | Before (stock engine) | After (this PR) -- | -- | -- | -- Launch closed | 1398x2034 | 1398x2034 | 1398x2034 Closed → open | 2007x2853 | ❌ 1398x2034 | ✅ 2007x2853 Open → closed | 1398x2034 | 1398x2034 | ✅ 1398x2034 Launch open (first read in main()) | 2007x2853 | ❌ 1398x2034 for the whole session | ✅ 2007x2853 Working towards flutter#195177 *If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].* ## Pre-launch Checklist - [x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs. - [x] I read the [AI contribution guidelines] and understand my responsibilities, or I am not using AI tools. - [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 in-code documentation (doc comments with `///`). - [x] If this PR introduces a new feature or capability, I created and linked a website documentation issue or PR in [flutter/website] (or verified none is needed). - [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. - [ ] All existing and new tests are passing. If you need help, consider asking for advice on the #hackers-new channel on [Discord]. If this change needs to override an active code freeze, provide a comment explaining why. The code freeze workflow can be overridden by code reviewers. See pinned issues for any active code freezes with guidance. **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 [AI contribution guidelines]: https://github.com/flutter/flutter/blob/main/CONTRIBUTING.ai.md [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 [flutter/website]: https://github.com/flutter/website [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
|
@hellohuanlin 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 updates the iOS platform code to retrieve display and screen information from the specific screen the Flutter view is currently on, rather than always defaulting to the main screen. It also tracks the last sent display size and scale to prevent redundant updates, and updates the accessibility frame calculation in SemanticsObject to use the view's screen. The review feedback suggests simplifying the screen retrieval by using window.screen directly instead of window.windowScene.screen, which would also simplify the corresponding unit test mocks.
|
This needs an area expert, or TL, to approve and green tests before this can merge. @hellohuanlin or @vashworth can yall take care of that then ping me. This is the last opportunity to land changes before the beta to stable promotion. |
|
@reidbaker thanks. we are just waiting for the build now |
|
@reidbaker fyi the test has passed |
e34e4dd
into
flutter:flutter-3.50-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?
#195177
Impact Description:
What is the impact (ex. visual jank on Samsung phones, app crash, cannot ship an iOS app)?
Wrong display size being sent to dart side on iPhone Duo's inner display. This can cause rendering issues and accessibility issues.
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.
Impact production apps that runs on iPhone Duo's inner display.
Changelog Description:
Explain this cherry pick:
See best practices for examples.
[flutter/195177] When running on iPhone Duo, Report the correct display size to dart side when switching between inner and outer displays.
Workaround:
Is there a workaround for this issue?
No
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?
Test on this sample app using local engine on iPhone Duo simulator.