[Problem/Bug]: CoreWebView2WindowFeatures/ICoreWebView2WindowFeatures returning invalid values for top and left when provided with negative values in window.open()

[mikamikem]

What happened?

The top and left values on ICoreWebView2WindowFeatures and CoreWebView2WindowFeatures appear to be signed integer values that are simply cast to unsigned integer values. If a website uses negative values (which should be invalid for these properties), the values returned are not uint.MaxValue as the docs specify, but a very large uint value that corresponds to the negative value cast to a uint.

Importance

Important. My app's user experience is significantly compromised.

Runtime Channel

Stable release (WebView2 Runtime)

Runtime Version

126.0.2544.0

SDK Version

1.0.1722.45

Framework

WPF

Operating System

Windows 10

OS Version

19045.4355

Repro steps

1. Go to https://javascript.info/popup-windows#example-a-minimalistic-window
2. Click the run button on the first example to open a popup with a negative left and top value.
3. Observe the values returned by CoreWebView2WindowFeatures.Top and CoreWebView2WindowFeatures.Left.

Expected:
Both values should be uint.MaxValue because negative values are invalid for these fields.

Observed
Values are uint.MaxValue - 1000 + 1 which is the signed integer value of -1000 used in the example.

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

AB#46380638

[johna-ms]

Thanks for reporting this! I can repro this and am adding it to our backlog

[awolbach]

While researching #4826 I found that on a workstation with multiple screens where the screens are oriented horizontally, the web application sees a layout where the bounds of the screens are bottom-aligned (obviously, this only becomes evident if the screens have different heights). Then in the case where the primary screen is logically shorter than another screen, the browser seems to preferentially assign the primary screen a top value of 0, which combined with the bottom-alignment results in the other screen receiving a negative top value.

I've been assuming this behavior was correct. W3 states that "coordinates may be negative" in the virtual screen arrangement and "a common convention is to set the multi-screen origin to the top-left of the primary screen", and so I found this issue searching for its opposite: it seems like the left and top properties should be signed integers. It's fortunate that the values are passed through untouched and can simply be cast back to signed integers; if top was changed to uint.MaxValue, a floating window could not be positioned in the higher part of the taller screen using the window features.

Below I've pasted a screenshot from Edge on my Win11 workstation, which has two 1920x1080 monitors with the Scale setting set to 150% on the left, primary monitor (shrinking it logically to 1280x720). I would have taken this screenshot from a WebView2 application but I can't get a good screenshot because of #4826, but presumably when that is fixed, it will show the same behavior. Chrome shows the same values.