> screen.height - width of system bar + launch bar I'm sorry screen.height - width of system bar *-* launch bar
On Wed, Nov 4, 2026 at 5:38 PM Daniil Hrybchuk <[email protected]> wrote: > Hello Alex, > > > the majority of Android devices > > we'd only be looking to change things on desktop-format Androids > > These changes will be rolled out across all Android platforms, though the > impact will only be visible on desktop devices, as most mobile website > versions do not use these values. > > > And what do we return today for mobile devices for these values? > > Without these changes: > > 1. screen.availLeft == screen.left > > 2. screen.availTop == screen.top > > 3. screen.availHeight == screen.height > > 4. screen.availWidth == screen.width > > > With these changes > > 1. screen.availLeft == screen.left (Currently, no devices have UI elements > on the sides, but we will account for them if any are introduced.) > > 2. screen.availTop == width of system bar > > 3. screen.availHeight == screen.height - width of system bar + launch bar > (on desktop) > > 4. screen.availWidth == screen.width (Currently, no devices have UI > elements on the sides, but we will account for them if any are introduced.) > > > > > And are we bringing the behaviour into line with other desktop OSes? > > Yes, this is the main reason for these changes. > > On Wed, Nov 4, 2026 at 5:25 PM Alex Russell <[email protected]> > wrote: > >> Hey Daniil, >> >> Thanks for all of this. Viewport sizes have indeed been a running problem >> on mobile, so I'm glad we're improving things in this area. >> >> We discussed this in today's API OWNERS call, and the major question here >> is the potential for breakage. If we understand correctly, this won't' >> really impact the majority of Android devices, and we'd only be looking to >> change things on desktop-format Androids? And what do we return today for >> mobile devcies for these values? And are we bringing the behaviour into >> line with other desktop OSes? >> >> Thanks, >> >> Alex >> >> >> On Wednesday, November 4, 2026 at 4:51:58 AM UTC-8 Daniil Hrybchuk wrote: >> >>> Hello Alex, >>> >>> Sorry for the late reply. Just to make sure I'm addressing what you're >>> asking: >>> >>> > but I'm wondering if we really have no input from developers? >>> >>> 1. If you mean "Are there any complaints about the current behavior?" – >>> I've found several discussions highlighting developer pain points: >>> >>> - >>> >>> https://stackoverflow.com/questions/7838488/how-to-get-the-correct-android-available-screen-height-of-the-browser-in-javascr/8414510 >>> >>> <https://www.google.com/url?q=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F7838488%2Fhow-to-get-the-correct-android-available-screen-height-of-the-browser-in-javascr%2F8414510> >>> - >>> >>> https://stackoverflow.com/questions/12643314/javascript-max-viewport-height-after-orientation-change-android-ios >>> >>> <https://www.google.com/url?q=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F12643314%2Fjavascript-max-viewport-height-after-orientation-change-android-ios> >>> - https://tripleodeon.com/2011/12/first-understand-your-screen/ >>> >>> <https://www.google.com/url?q=https%3A%2F%2Ftripleodeon.com%2F2011%2F12%2Ffirst-understand-your-screen%2F> >>> - >>> >>> https://stackoverflow.com/questions/16104434/getting-reliable-available-width-and-height-using-javascript/16166086#16166086 >>> >>> <https://www.google.com/url?q=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F16104434%2Fgetting-reliable-available-width-and-height-using-javascript%2F16166086%2316166086> >>> >>> 2. If you mean "Will this break anything?" – The experiment has been >>> running on Stable for over two months, and we haven't received any bug >>> reports or negative feedback so far. >>> >>> >>> On Wed, Oct 21, 2026 at 5:32 PM Alex Russell <[email protected]> >>> wrote: >>> >>>> This feels like a useful change, but I'm wondering if we really have no >>>> input from developers? >>>> >>>> On Wednesday, October 21, 2026 at 3:37:20 AM UTC-7 Chromestatus wrote: >>>> >>>>> *Contact emails* >>>>> [email protected] >>>>> >>>>> *Explainer* >>>>> https://developer.mozilla.org/en-US/docs/Web/API/Screen >>>>> >>>>> *Specification* >>>>> https://developer.mozilla.org/en-US/docs/Web/API/Screen >>>>> >>>>> *Design docs* >>>>> >>>>> >>>>> https://docs.google.com/document/d/1AccF_jc0ZgnM10YZSRzMjoTyJefKUH1A4OwaDcm1s9Y >>>>> >>>>> *Summary* >>>>> The screen.avail properties account for system UI elements when >>>>> calculating available screen space on Android. This provides developers >>>>> with the exact usable display area needed to accurately place application >>>>> windows on Android. >>>>> >>>>> *Blink component* >>>>> Blink>Screen >>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EScreen%22> >>>>> >>>>> *Web Feature ID* >>>>> screen <https://webstatus.dev/features/screen> >>>>> >>>>> *Motivation* >>>>> These changes in screen.avail properties provide developers with the >>>>> exact usable display area needed to accurately place application windows. >>>>> Consequently, popups and windows appear in the correct locations without >>>>> overlapping the operating system interface. >>>>> >>>>> *Initial public proposal* >>>>> *No information provided* >>>>> >>>>> *TAG review* >>>>> *No information provided* >>>>> >>>>> *TAG review status* >>>>> Not applicable >>>>> >>>>> *Goals for experimentation* >>>>> None >>>>> >>>>> *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? >>>>> *No information provided* >>>>> >>>>> >>>>> *Debuggability* >>>>> *No information provided* >>>>> >>>>> *Will this feature be supported on all six Blink platforms (Windows, >>>>> Mac, Linux, ChromeOS, Android, and Android WebView)?* >>>>> No >>>>> >>>>> *Is this feature fully tested by web-platform-tests >>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>>>> No >>>>> >>>>> >>>>> *Flag name on about://flags* >>>>> android-use-correct-display-work-area >>>>> >>>>> *Finch feature name* >>>>> AndroidUseCorrectDisplayWorkArea >>>>> >>>>> *Rollout plan* >>>>> Will ship enabled for all users >>>>> >>>>> *Requires code in //chrome?* >>>>> False >>>>> >>>>> *Estimated milestones* >>>>> >>>>> No milestones specified >>>>> >>>>> >>>>> *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 information provided* >>>>> >>>>> *Link to entry on the Chrome Platform Status* >>>>> https://chromestatus.com/feature/4824062942642176?gate=5662595311861760 >>>>> >>>>> *Links to previous Intent discussions* >>>>> Intent to Prototype: >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69d79280.050a0220.2357b3.0230.GAE%40google.com >>>>> >>>>> >>>>> This intent message was generated by Chrome Platform Status >>>>> <https://chromestatus.com>. >>>>> >>>> >>> >>> -- >>> Daniil Hrybchuk >>> Software Engineer – ChromeOS >>> [email protected] >>> >> > > -- > Daniil Hrybchuk > Software Engineer – ChromeOS > [email protected] > -- Daniil Hrybchuk Software Engineer – ChromeOS [email protected] -- 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/CAC7xZCLBEqoYgqG9wS6muAAwJoZDUMj-_1DK4Ea9%2BdAxixV7HA%40mail.gmail.com.
