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
<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.
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.
>> *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/b1cbd104-6516-4c31-9de5-ddb52f10bfcc%40chromium.org.
