You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When two monitors are used the Downloads Hub flyout is never at the intersection of the two monitors. It will always find the most available space and jump on to that monitor regardless of the application frame. But on NEW WebView Teams, this will always jump on to the next monitor when the window is maximized.
I've first faced this issue in this New WebView Teams, so I went on an exploration to find out how it behaves in other apps as my assumption was this has something to do with WebView. Later on, I also created a WinForms app to better understand the flyouts behavior. Here are my findings:
App \ State
Maximized
Windowed
Windowed between monitors
Microsoft Teams (work or school)
Overflows to the next monitor
Stays within the application frame
Overflows if available screen size < Full flyout size with shadows
Microsoft Teams (Personal)
Stays within the application frame
Stays within the application frame
Overflows if available screen size < Full flyout size with shadows
Edge Stable
Stays within the application frame
Stays within the application frame anchored to the Downloads icon in toolbar 1
Overflows if available screen size < Full flyout size with shadows; Anchored to the Downloads icon in toolbar 1
WinForms WebView2
Stays within the application frame
Stays within the application frame
Overflows if available screen size < Full flyout size with shadows
Screenshots
Screenshot 1: New Microsoft Teams WebView (work or school) in maximized window. Overflows to the next monitor.
Screenshot 2: Mircrosoft Teams Personal in maximized window. Does not overflow to the next monitor.
Screenshot 3: My WinForms Demo. Overflows when there is less space to keep the flyout in one piece between two monitors.
Why opening this issue?
The purposes of opening this issue are:
to know the intended behavior for these flyouts
to establish a documentation for these flyout behaviors
to know are there any ways to make them respect the application window boundaries when they're maximized
Edge seems to have an anchoring for these Views flyout. Are there any API that third party developers can use to anchor these flyouts to a desired location within the application frame?
Importance
Moderate. My app's user experience is affected, but still usable.
Runtime Channel
Stable release (WebView2 Runtime)
Runtime Version
122.0.2365.92
SDK Version
1.0.2365.46
Framework
Winforms
Operating System
Windows 11
OS Version
22631.3296
Repro steps
Before we begin:
This issue will require you to have dual monitors. If you do not have dual monitor, you can still use a laptop with an external display or same resolution projector in Extend mode (Win+P). My setup is two Dell monitors both 1080p resolution but in different PPI. Monitor 1 is Dell P2419H a 23.8" panel at 92 PPI @ 100% scaling. Monitor 2 is Dell S2240L a 21.5" panel at 102 PPI @ 100% scaling.
You can also build your own application with WinForms or WPF or Win32. Get the official WebView2 NuGet package. Make the WebView dock in Fill mode. Set the source URL to any preferable website that offers downloads. Click on the download and observe the flyout behaviors. You can also skip this by setting the URL to any website and when the application launches press Ctrl+J. Keep in mind this won't work on blank source URL.
If you want to skip the building process and you already have any application that uses WebView e.g. Teams (work or school) you can test it there too. Teams (work or school) is the only one that overflows the Downloads flyout to the next monitor when it is maximized.
Current behavior:
The download flyout overflows/shifts to next monitor if there isn't available space to draw the flyout in one piece.
Expected behavior:
The download flyout is within the application boundary when it is between two monitors or there is available API to position them freely.
This does not affect my application but in Teams it looks out of context when the flyout is on next monitor while the whole app is maximized here in first monitor. I'll also submit an issue in Teams later.
Edge seems to overcome this issue slightly by anchoring the flyouts to the icons.
Repros in Edge Browser
No, issue does not reproduce in the corresponding Edge version
Regression
Don't know
Last working version (if regression)
No response
Footnotes
It seems that the flyout at first pops up at a default location somewhere beside the application frame at top-right or within the application frame at top-right (depending on the available screen size to show it up in one piece) and then finds its anchor to move there. Download icon on the title bar is hidden to show the anchoring behavior. It shows up when the Hub is opened/downloads initiated. See: The animation
Opens up at a default location
Finds its anchor
Moved to the anchor ↩↩2
The text was updated successfully, but these errors were encountered:
@abmprottoy I tried to repro this issue on Teams but couldn't, the download hubs stay in the main monitor consistently for both versions of Teams. I will try to test it on Winforms and try to match your monitor set up the best I could but so far for Teams, download hub seems to behave the same for both.
My runtime version is 126, could you also try again with 126 and let us know is you are still seeing the issue with your set up?
@tofuandeve Sorry for the delay as I'm in the middle of a semester finals week. Because I have to use Teams (Work and School) almost daily, I've also noticed that recently the Download Hub is staying within the window frame.
Here's the WebView details for Teams:
The runtime version is 124.0.2478.67
I guess this concludes that the Maximized behavior of Teams (Overflows to the next monitor) as Application specific bug and has since been fixed.
After opening this issue and using the flyouts a few more times in dual monitor setup, I have come to conclusion that these might be the intended behaviors to move the flyouts to where the most space is available as not every setup has thin bezels between the monitors to make the gap less distracting. So, it makes sense to move them completely to another monitor.
I'd like to emphasize the purpose of opening this issue that I'm more interested in knowing the intended behaviors or establish a documentation for these Hubs anchoring behaviors. And finally, I'd like to know if there's any custom anchoring mechanism for these Hubs so we can anchor them to custom icons in the window frame. If there's available, then is it documented.
What happened?
When two monitors are used the Downloads Hub flyout is never at the intersection of the two monitors. It will always find the most available space and jump on to that monitor regardless of the application frame. But on NEW WebView Teams, this will always jump on to the next monitor when the window is maximized.
I've first faced this issue in this New WebView Teams, so I went on an exploration to find out how it behaves in other apps as my assumption was this has something to do with WebView. Later on, I also created a WinForms app to better understand the flyouts behavior. Here are my findings:
Screenshots
Screenshot 1: New Microsoft Teams WebView (work or school) in maximized window. Overflows to the next monitor.
Screenshot 2: Mircrosoft Teams Personal in maximized window. Does not overflow to the next monitor.
Screenshot 3: My WinForms Demo. Overflows when there is less space to keep the flyout in one piece between two monitors.
Why opening this issue?
The purposes of opening this issue are:
Importance
Moderate. My app's user experience is affected, but still usable.
Runtime Channel
Stable release (WebView2 Runtime)
Runtime Version
122.0.2365.92
SDK Version
1.0.2365.46
Framework
Winforms
Operating System
Windows 11
OS Version
22631.3296
Repro steps
Before we begin:
This issue will require you to have dual monitors. If you do not have dual monitor, you can still use a laptop with an external display or same resolution projector in Extend mode (Win+P). My setup is two Dell monitors both 1080p resolution but in different PPI. Monitor 1 is Dell P2419H a 23.8" panel at 92 PPI @ 100% scaling. Monitor 2 is Dell S2240L a 21.5" panel at 102 PPI @ 100% scaling.
Repro
To reproduce the issue I've created a demo WinForms application available from my Azure DevOps Repository. https://abmprottoy.visualstudio.com/_git/WebViewFlyoutTest
From there:
You can also build your own application with WinForms or WPF or Win32. Get the official WebView2 NuGet package. Make the WebView dock in Fill mode. Set the source URL to any preferable website that offers downloads. Click on the download and observe the flyout behaviors. You can also skip this by setting the URL to any website and when the application launches press Ctrl+J. Keep in mind this won't work on blank source URL.
If you want to skip the building process and you already have any application that uses WebView e.g. Teams (work or school) you can test it there too. Teams (work or school) is the only one that overflows the Downloads flyout to the next monitor when it is maximized.
Current behavior:
The download flyout overflows/shifts to next monitor if there isn't available space to draw the flyout in one piece.
Expected behavior:
The download flyout is within the application boundary when it is between two monitors or there is available API to position them freely.
This does not affect my application but in Teams it looks out of context when the flyout is on next monitor while the whole app is maximized here in first monitor. I'll also submit an issue in Teams later.
Edge seems to overcome this issue slightly by anchoring the flyouts to the icons.
Repros in Edge Browser
No, issue does not reproduce in the corresponding Edge version
Regression
Don't know
Last working version (if regression)
No response
Footnotes
It seems that the flyout at first pops up at a default location somewhere beside the application frame at top-right or within the application frame at top-right (depending on the available screen size to show it up in one piece) and then finds its anchor to move there. Download icon on the title bar is hidden to show the anchoring behavior. It shows up when the Hub is opened/downloads initiated. See: The animation
Opens up at a default location
Finds its anchor
Moved to the anchor ↩ ↩2
The text was updated successfully, but these errors were encountered: