Constrain RawAutocomplete options by soft keyboard#163868
Constrain RawAutocomplete options by soft keyboard#163868victorsanni wants to merge 13 commits intoflutter:masterfrom
Conversation
|
Golden file changes have been found for this pull request. Click here to view and triage (e.g. because this is an intentional change). If you are still iterating on this change and are not ready to resolve the images on the Flutter Gold dashboard, consider marking this PR as a draft pull request above. You will still be able to view image results on the dashboard, commenting will be silenced, and the check will not try to resolve itself until marked ready for review. For more guidance, visit Writing a golden file test for Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. |
|
Instead of making the options view shorter, can you move the autocomplete widget up? I believe you can override https://main-api.flutter.dev/flutter/rendering/RenderObject/showOnScreen.html to achieve that. |
| fieldOffset = nextFieldOffset; | ||
| }); | ||
| } | ||
| bottomInset = MediaQuery.viewInsetsOf(rootOverlayContext).bottom; |
There was a problem hiding this comment.
So viewInsets is accounted for in the calculation, but not the viewPadding? Do you think we should be using padding here?
There was a problem hiding this comment.
Also, why bottom only if the insets may have positive top value, for example?
There was a problem hiding this comment.
About both questions, I'm not sure. Currently the options view just takes up the space on the entire screen, ignoring safearea, view padding and all that. I'm not sure if this is intentional or not. @justinmc what do you think?
There was a problem hiding this comment.
This comment doesn't seem to have been addressed?
There was a problem hiding this comment.
Also, why
bottomonly if the insets may have positivetopvalue, for example?
The documentation for MediaQuery.viewInsets says only .bottom is relevant because of the system keyboard? Unless I am missing something.
| removeCompositionCallback = widget.optionsLayerLink.leader?.addCompositionCallback( | ||
| _onLeaderComposition, | ||
| ); | ||
| rootOverlayContext = Overlay.of(context).context; |
There was a problem hiding this comment.
This does not necessarily target the root overlay if there are nested Overlays, as the variable name would indicate it seems?
There was a problem hiding this comment.
That's true. The reason for this is to grab the context before the Scaffold applies Mediaquery.removePadding (when Scaffold.resizeToAvoidBottomInset is set to true), and this would no longer work if there is an Overlay between RawAutocomplete and Scaffold in the widget tree. But I don't know any better alternatives, do you have any ideas?
There was a problem hiding this comment.
I think it should target the root overlay now after the suggestion in #163868 (comment)
| fieldOffset = nextFieldOffset; | ||
| }); | ||
| } | ||
| bottomInset = MediaQuery.viewInsetsOf(rootOverlayContext).bottom; |
There was a problem hiding this comment.
This comment doesn't seem to have been addressed?
justinmc
left a comment
There was a problem hiding this comment.
LGTM with some questions, but I'll defer to @LongCatIsLooong
justinmc
left a comment
There was a problem hiding this comment.
Renewing my LGTM, thanks for the changes 👍
| // The padding and view insets might have already been removed. To get the | ||
| // correct padding and view insets, use the build context of the root | ||
| // overlay. | ||
| final EdgeInsets padding = MediaQuery.paddingOf(rootOverlayContext); |
There was a problem hiding this comment.
The padding and view insets might have already been removed.
Then this probably should happen in the OverlayPortal implementation, so the overlayChild sees the correct MediaQuery?
There was a problem hiding this comment.
But in that case how would the CustomSingleChildLayout get the padding values to apply to the child constraints? Maybe the MediaQuery.removePadding should happen in the OverlayPortal implementation over the entire overlaychild, but the padding values should still be retrieved here?
There was a problem hiding this comment.
You can still get it from MediaQueryData?
| VoidCallback? removeCompositionCallback; | ||
| late BuildContext rootOverlayContext; | ||
| double bottomPadding = 0.0; | ||
| double topPadding = 0.0; |
There was a problem hiding this comment.
Again, why bottom / top paddings specifically? Shouldn't we keep track of the EdgetInsets to avoid?
There was a problem hiding this comment.
Add left and right as well?
There was a problem hiding this comment.
Just keep the EdgeInsets? or better yet it doesn't have to be kept in instance variables if you update the MediaQuery of the overlayChild
|
Hi @LongCatIsLooong. Will #170818 also unblock this PR? |
Yeah I think so |
Normally I would say greetings from stale PR triage, but now I see why you asked about #170818, I did not realize this was blocked on that. I'll see if I can turn that around ASAP. 👍 |
|
I am going to suggest closing this for now. I am working with a contributor on the blocking issue, after which we can reopen this - although it may be easier to resolve the conflicts and update for the large lint overhaul in a fresh PR. :) |
|
Reopening as blocker has been resolved. |
|
An existing Git SHA, To re-trigger presubmits after closing or re-opeing a PR, or pushing a HEAD commit (i.e. with |
|
Easier to close and open a new PR because of the merge conflicts. |
Fixes Autocomplete options overlay should automatically moves up when soft keyboard is visible
Before
before.soft.keyboard.mov
After
Screen.Recording.2025-02-28.at.4.04.29.PM.mov
Sample code
Pre-launch Checklist
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.