-
Notifications
You must be signed in to change notification settings - Fork 8.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
default profile menu once opened in startup settings goes above the window when scrolling down #9320
Comments
Holy man that's bad. This is definitely a WinUI bug - I'll move it over there tomorrow morning. Thanks! |
Tracking microsoft/microsoft-ui-xaml#4554 upstream |
…0922) ## Summary of the Pull Request BODGY! This solution was suggested in microsoft/microsoft-ui-xaml#4554 (comment). When the window moves, or when a ScrollViewer scrolls, dismiss any popups that are visible. This happens automagically when an app is a real XAML app, but it doesn't work for XAML Islands. ## References * upstream at microsoft/microsoft-ui-xaml#4554 ## PR Checklist * [x] Closes #9320 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments Unfortunately, we've got a bunch of scroll viewers in our SUI. So I did something bodgyx2 to make our life a little easier. `DismissAllPopups` can be used to dismiss all popups for a particular UI element. However, we've got a bunch of pages with scroll viewers that may or may not have popups in them. Rather than define the same exact body for all their `ViewChanging` events, the `HasScrollViewer` struct will just do it for you! Inside the `HasScrollViewer` stuct, we can't get at the `XamlRoot()` that our subclass implements. I mean, _we_ can, but when XAML does it's codegen, _XAML_ won't be able to figure it out. Fortunately for us, we don't need to! The sender is a UIElement, so we can just get _their_ `XamlRoot()`. So, you can fix this for any SUI page with just a simple ```diff - <ScrollViewer> + <ScrollViewer ViewChanging="ViewChanging"> ``` ```diff - struct AddProfile : AddProfileT<AddProfile> + struct AddProfile : public HasScrollViewer<AddProfile>, AddProfileT<AddProfile> ``` ## Validation Steps Performed * the window doesn't close when you move it * the popups _do_ close when you move the window * the popups close when you scroll any SUI page
…0922) BODGY! This solution was suggested in microsoft/microsoft-ui-xaml#4554 (comment). When the window moves, or when a ScrollViewer scrolls, dismiss any popups that are visible. This happens automagically when an app is a real XAML app, but it doesn't work for XAML Islands. * upstream at microsoft/microsoft-ui-xaml#4554 * [x] Closes #9320 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated Unfortunately, we've got a bunch of scroll viewers in our SUI. So I did something bodgyx2 to make our life a little easier. `DismissAllPopups` can be used to dismiss all popups for a particular UI element. However, we've got a bunch of pages with scroll viewers that may or may not have popups in them. Rather than define the same exact body for all their `ViewChanging` events, the `HasScrollViewer` struct will just do it for you! Inside the `HasScrollViewer` stuct, we can't get at the `XamlRoot()` that our subclass implements. I mean, _we_ can, but when XAML does it's codegen, _XAML_ won't be able to figure it out. Fortunately for us, we don't need to! The sender is a UIElement, so we can just get _their_ `XamlRoot()`. So, you can fix this for any SUI page with just a simple ```diff - <ScrollViewer> + <ScrollViewer ViewChanging="ViewChanging"> ``` ```diff - struct AddProfile : AddProfileT<AddProfile> + struct AddProfile : public HasScrollViewer<AddProfile>, AddProfileT<AddProfile> ``` * the window doesn't close when you move it * the popups _do_ close when you move the window * the popups close when you scroll any SUI page
🎉This issue was addressed in #10922, which has now been successfully released as Handy links: |
🎉This issue was addressed in #10922, which has now been successfully released as Handy links: |
Environment
Windows build number: Version 10.0.19042.844
Windows Terminal version (if applicable): 1.7.572.0
Any other software?
Steps to reproduce
Settings-Startup-Default profile (tap arrow to open) and scroll down the window using mouse (the window not in maximize mode)
Expected behavior
selection menu (Windows PowerShell, Command Prompt, Azure Cloud Shell) - when expanded (while scrolling down) it does not move to the screen above the Windows PowerShell window (the window is not in maximize mode)
Actual behavior
The selection menu (Windows PowerShell, Command Prompt, Azure Cloud Shell) goes beyond the top edge of the Windows PowerShell window if the window is not in maximize mode
The text was updated successfully, but these errors were encountered: