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 On Tue, Dec 16, 2025 at 1:38 AM Mike Taylor <[email protected]> wrote: > 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/CAAz0gKe_2Bd21nRPk8xx%3DX_u1tAKWtOrnL4_wNX-U0VoBaku5Q%40mail.gmail.com.
