LGTM3 On Wednesday, December 17, 2025 at 4:06:36 PM UTC+1 Chris Harrelson wrote:
> 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/f344771a-230d-4a74-b786-777f3e8daea3n%40chromium.org.
