LGTM2 On Tue, Dec 16, 2025 at 12:33 AM 'Bartosz Chomiński' via blink-dev < [email protected]> wrote:
> 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAz0gKe_2Bd21nRPk8xx%3DX_u1tAKWtOrnL4_wNX-U0VoBaku5Q%40mail.gmail.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/CAOMQ%2Bw9W7WSi4-A0onuD%2B7v229aZJoF64s9Ff5bq5KEWbE7Y7w%40mail.gmail.com.
