victorhuangwq
commented
7 months ago @abmprottoy thank you for the detailed report, @bradp0721 could you help take a look at this issue?
Closed abmprottoy closed 5 days ago
victorhuangwq
commented
7 months ago @abmprottoy thank you for the detailed report, @bradp0721 could you help take a look at this issue?
tofuandeve
commented
6 months ago @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?
abmprottoy
commented
6 months ago @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.
Thank you everyone for looking into this.
tofuandeve
commented
5 days ago @abmprottoy Right now, in terms of positioning, we only support setting default download dialog alignment to any of the WebView corners https://github.com/MicrosoftEdge/WebView2Feedback/blob/main/specs/DefaultDownloadDialog.md
Closing the bug as the original issue has been fixed.
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:
[^1]: 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
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