Intent to Ship: Show true window position on Android

[Chromestatus]

Contact emails

chomi...@google.com

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

Web Feature ID

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, position, screen, coordinates, android

TAG review

No information provided

TAG review status

Not applicable

Risks

Interoperability and Compatibility

No information provided

Gecko: No signal

WebKit: No signal

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?

No

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.

[Mike Taylor]

On 12/10/25 1:00 p.m., Chromestatus wrote:

Contact emails

chomi...@google.com

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

Web Feature ID

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, position, screen, coordinates, 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?

No 

This probably isn't correct. Can you point to the relevant tests please?

--
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 blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6939b532.710a0220.1d2509.0737.GAE%40google.com.

[Bartosz Chomiński]

> 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 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 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?
>> 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

[Mike Taylor]

Thanks for the detailed reply!

LGTM1, this seems like a low-risk bug fix. 

On 12/15/25 1:05 p.m., Bartosz Chomiński wrote:

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

Presumably the pop-up is a DOM element, and not a new window, per your comment below.

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

Seems like an MDN bug then. 

• 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).

Makes sense, perhaps as an anti-fingerprinting measure. 

[Bartosz Chomiński]

Thanks for your LGTM.

> Presumably the pop-up is a DOM element, and not a new window, per your comment below.

The pop-up that PayPal launches is in principle an actual new browser window, created with window.open(). Sorry for the confusion – even though Chrome for Android does not officially support pop-ups in actual new windows yet, I've already implemented this feature behind a flag, enable-android-window-popup-large-screen, and that's how I was able to test what PayPal does on Android. New pop-up behavior should be available on Stable in 26Q2, after Android 17 is released.

Best,

Bartosz

[Chris Harrelson]

LGTM2

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAz0gKe_2Bd21nRPk8xx%3DX_u1tAKWtOrnL4_wNX-U0VoBaku5Q%40mail.gmail.com.

[Yoav Weiss (@Shopify)]

LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.