> This sounds like a straightforward bug fix, but there's possibly some scenario where sites are using 0 screenLeft/screenX values as a proxy for Android vs Desktop. Are we aware of sites or use cases that are broken today that will be fixed with this change?
The "PayPal Checkout" button seen on many e-commerce websites uses this data to launch a pop-up for payment authorization at the center of the original window hosting the e-commerce website. > What do the other browsers do in tablet (Safari, Firefox) or Android on desktop form factor (Firefox?) scenarios? Firefox already reports these values correctly on Android tablets besides from - a difference in accounting the space between the website viewport and the OS-level window (mostly occupied by the URL bar and tab strip) – MDN states <https://developer.mozilla.org/en-US/docs/Web/API/Window/screenX> that window.screenX "returns the horizontal distance, in CSS pixels, of the left border of the user's *browser viewport* to the left side of the screen." while the W3C Working Draft of CSSOM View Module states <https://www.w3.org/TR/cssom-view-1/#dom-window-screenx> that "The screenX and screenLeft attributes must return the x-coordinate, relative to the origin of the Web-exposed screen area, of the left of the *client window* as number of CSS pixels, or zero if there is no such thing.". Chrome on ChromeOS uses the latter approach and this feature for Android also uses the latter approach. - no support for multi-display topology – the screenX and screenY values provided by Firefox are always relative to the origin of the display currently hosting the browser window, not relative to the origin of the global coordinate system spanning all displays that uses data from OS-provided display topology. Safari reports window.screenX = 0 and window.screenY = 0 on iPad regardless of the actual position of the window on screen (fullscreen vs. right half in split-screen). >> *Is this feature fully tested by *web-platform-tests <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> *?*>> No > This probably isn't correct. Can you point to the relevant tests please? I was able to find tests that cross-check values reported by window.screen{X, Y} with values requested in a window.open() call. These are located at wpt/html/browsers/the-window-object/open-close/open-features-tokenization-screenx-screeny.html. However, since Chrome for Android does not support opening pop-ups as new windows yet, these tests will remain failing after this feature is launched. Moreover, there are tests verifying that window.screenLeft is an alias of window.screenX and the same assertion for window.screenTop and window.screenY, located at wpt/css/cssom-view/screenLeftTop.html. Best, Bartosz On Monday, December 15, 2025 at 3:51:58 PM UTC+1 Mike Taylor wrote: > On 12/10/25 1:00 p.m., Chromestatus wrote: > > *Contact emails* > [email protected] > > *Specification* > https://www.w3.org/TR/cssom-view-1/#dom-window-screenx > > *Summary* > Chrome on Android accurately reports the browser window's position and > size using window.screenX, window.screenY, window.outerWidth, and > window.outerHeight. Previously Chrome incorrectly assumed all browser > windows on Android start at coordinates (0, 0). This is inaccurate for > Android tablets using freeform windowing mode, causing websites to always > receive 0 when querying the window's on-screen position using > window.screenX and window.screenY (these fields store the coordinates of > window's top-left corner in global work area coordinate space). Moreover, > Chrome on Android incorrectly assumed that outer dimensions of the browser > window are equal to the inner dimensions of the website viewport. Remark: > window.screenX and window.screenY have aliases, window.screenLeft and > window.screenTop. > > *Blink component* > Blink>HTML > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EHTML%22> > > *Web Feature ID* > window <https://webstatus.dev/features/window> > > *Motivation* > Chrome on Android in desktop form factors should be in functional parity > with Chrome for other desktop operating systems. This includes the ability > to report valid window position to websites that query window.screenX or > window.screenY fields (also aliases, window.screenLeft and > window.screenTop). > > *Initial public proposal* > *No information provided* > > *Search tags* > window <http:///features#tags:window>, position > <http:///features#tags:position>, screen <http:///features#tags:screen>, > coordinates <http:///features#tags:coordinates>, android > <http:///features#tags:android> > > *TAG review* > *No information provided* > > *TAG review status* > Not applicable > > *Risks* > > This sounds like a straightforward bug fix, but there's possibly some > scenario where sites are using 0 screenLeft/screenX values as a proxy for > Android vs Desktop. Are we aware of sites or use cases that are broken > today that will be fixed with this change? > > *Interoperability and Compatibility* > *No information provided* > > *Gecko*: No signal > > *WebKit*: No signal > > What do the other browsers do in tablet (Safari, Firefox) or Android on > desktop form factor (Firefox?) scenarios? > > > *Web developers*: No signals > > *Other signals*: > > *WebView application risks* > > Does this intent deprecate or change behavior of existing APIs, such that > it has potentially high risk for Android WebView-based applications? > This should not change any observable behavior of WebView. > > > *Debuggability* > *No information provided* > > *Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, ChromeOS, Android, and Android WebView)?* > Yes > > *Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* > No > > This probably isn't correct. Can you point to the relevant tests please? > > > > *Flag name on about://flags* > android-use-correct-window-bounds > > *Finch feature name* > AndroidUseCorrectWindowBounds > > *Rollout plan* > Will ship enabled for all users > > *Requires code in //chrome?* > False > > *Tracking bug* > https://g-issues.chromium.org/issues/417632037 > > *Launch bug* > https://launch.corp.google.com/launch/4400019 > > *Availability expectation* > N/A – Chrome for Android catches up. > > *Adoption expectation* > Already widely adopted – recently 16% of all page loads use window.screenX > per https://chromestatus.com/metrics/feature/timeline/popularity/2712. > > *Adoption plan* > N/A > > *Non-OSS dependencies* > > Does the feature depend on any code or APIs outside the Chromium open > source repository and its open-source dependencies to function? > Depends on Android providing a public API for apps to learn whereabouts of > the windows they are in. > > *Estimated milestones* > Shipping on Android 145 > > *Anticipated spec changes* > > Open questions about a feature may be a source of future web compat or > interop issues. Please list open issues (e.g. links to known github issues > in the project for the feature specification) whose resolution may > introduce web compat/interop risk (e.g., changing to naming or structure of > the API in a non-backward-compatible way). > No spec changes – Chrome for Android catches up. > > *Link to entry on the Chrome Platform Status* > https://chromestatus.com/feature/5164958878531584?gate=6272126285512704 > > *Links to previous Intent discussions* > Intent to Prototype: > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAz0gKehdm7rOzKSmQZ99L%3DJoYs6XTOip8fbxBhAqB7F6YE7EQ%40mail.gmail.com > > > This intent message was generated by Chrome Platform Status > <https://chromestatus.com>. > > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6939b532.710a0220.1d2509.0737.GAE%40google.com > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6939b532.710a0220.1d2509.0737.GAE%40google.com?utm_medium=email&utm_source=footer> > . > > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2d23f774-2de0-447f-87e3-df0ba762dbf4n%40chromium.org.
