Skip to content
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

[Problem/Bug]: Downloads Hub flyout escapes application boundary in multiple monitor setup #4442

Open
4 tasks
abmprottoy opened this issue Mar 22, 2024 · 3 comments
Assignees
Labels
bug Something isn't working

Comments

@abmprottoy
Copy link

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:

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 New Teams
Screenshot 1: New Microsoft Teams WebView (work or school) in maximized window. Overflows to the next monitor.

Screenshot Teams Personal
Screenshot 2: Mircrosoft Teams Personal in maximized window. Does not overflow to the next monitor.

Screenshot Winforms
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.

Display setup

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:

  • Clone or download the repository.
  • Open the solution in Visual Studio.
  • Build and run the WinForms application.
  • Install the WebView2 NuGet package if missing.
  • Observe the behavior of the Downloads Hub flyout.

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

  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: Animation The animation
    Opens up at a default location Opens up at a default location
    Finds its anchor Finds its anchor
    Moved to the anchor Moved to the anchor 2

@abmprottoy abmprottoy added the bug Something isn't working label Mar 22, 2024
@victorhuangwq
Copy link
Collaborator

@abmprottoy thank you for the detailed report, @bradp0721 could you help take a look at this issue?

@tofuandeve
Copy link
Contributor

@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
Copy link
Author

abmprottoy commented Apr 29, 2024

@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.

image

Here's the WebView details for Teams:
image

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants