Repository navigation
Conversation
DisplayFeatureSubScreen lays its child out in one sub-screen of a foldable, but the child's MediaQuery still reported the size of the whole screen, so a dialog confined to one half read the full width from MediaQuery.sizeOf. The display features left in the MediaQuery also kept screen coordinates, although the docs say they are relative to the sub-screen. The child's MediaQuery now has the size of the sub-screen, and the display features are shifted to be relative to it. The DateRangePicker display feature tests now use a 1600x600 screen: each half of an 800x600 screen is portrait, so the picker now uses its portrait layout there, whose header doesn't fit the test font in 390 pixels. Fixes flutter#192667
|
This pull request contains changes to Material or Cupertino, which are currently frozen in this repository. Changes should be made in Please refer to #188444 for instructions. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
DisplayFeatureSubScreenlays its child out in one sub-screen, but the child'sMediaQuerystill had the size of the whole screen. A dialog, bottom sheet or popup confined to one half of a foldable read the full screen width fromMediaQuery.sizeOf, so layouts based on it (for example portrait or landscape) were chosen for the wrong size.The display features left in the child's
MediaQueryalso kept screen coordinates, although the class docs say they are relative to the sub-screen.The child's
MediaQuerynow has the size of the selected sub-screen, and its display features are shifted to be relative to it. When there is no splitting display feature, theMediaQueryDatais passed through unchanged.MediaQueryData.removeDisplayFeaturesis not changed, since its tests expect it to keepsize.Effect on
showDateRangePicker: each half of an 800x600 screen with a vertical hinge is 390x600, which is portrait, so the picker now uses its portrait layout there. The three "avoids overlapping display features" tests indate_range_picker_test.dartthen failed with a RenderFlex overflow in the portrait header, because the test font is wider than a real font at 390 pixels. They now use a 1600x600 screen with the hinge at 790-810, so each half stays landscape and the tests still check which side of the hinge the dialog is placed on.Tests: the new tests check the child's size and display feature coordinates, and that the
MediaQueryDatais unchanged without splitting features. The size test fails without this change. The test files that use display features (display_feature_sub_screen_test.dart,media_query_test.dart,routes_test.dart, and the material and cupertino dialog, popup menu, bottom sheet, date picker, date range picker, time picker, about and menu anchor tests) pass.Fixes #192667
Pre-launch Checklist
///).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. Comments from the
gemini-code-assistbot 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.