Bug 52653 – Media queries should ignore scroll bars when calculating width of viewport

• Component: CSS
• Status: NEW

[Lars Gunther]

Webkit does not follow the spec, nor does it align with other browsers, when calculating the viewport width for media queries.

> The ‘width’ media feature describes the width of the targeted display area of the output device.
> For continuous media, this is the width of the viewport (as described by CSS2, section 9.1.1 [CSS21])
> including the size of a rendered scroll bar (if any).

Currently scroll bars are not included.

[Alexey Proskuryakov]

See also: bug 18954.

[Fabian]

Same issue here on Safari 13.1.1.

Execute this on a page with a scrollbar to verify:
```
window.matchMedia(`screen and (max-width: ${window.innerWidth-15}px)`).matches
```

This will return `true` on Safari (because the scrollbar has width 15px), but `false` on all other browsers.

It does not sound too bad, but this can have a very ugly impact:
Imagine your @media queries result in "Phone" layout being detected and when you open a full-screen modal dialog, you want to block scrolling on the body, and set "overflow: hidden" on it. This hides the scrollbar, which makes "document.body.clientWidth" wider, possibly now being detected as "Tablet" layout and causing other css @media rules to become active and mediaquery listeners to fire. In our case it caused the modal to being hidden immediately.

[Olivier Tassinari]

The same bug has been reported in https://github.com/mui-org/material-ui/issues/22812 on Safari 14.0

[Ahmad Saleem]

I am able to reproduce this bug in Safari Technology Preview 152 using steps to reproduce on "Comment 02" on this bug page (since it has scrollbar) and it shows "true" for Safari but other browsers (Chrome Canary 107 and Firefox Nightly 106) show "false".

I am changing status to "New" but if it is something other browsers need to fix, please update this accordingly. Thanks!

[Radar WebKit Bug Importer]

<rdar://problem/99527303>

[Šime Vidas]

Since in Safari, CSS media queries take classic scrollbars into account, I tried to determine how Safari prevents infinite loops that can be caused in such an environment.

I’ve uploaded two videos that show Safari’s behavior: https://mastodon.social/@simevidas/111128752905785569

Observations:

* Safari shows empty scrollbar gutters. The scrollbar is not present, but the scrollbar gutter is still there, and as a result, the viewport size is reduced.

* The value returned by document.documentElement.clientWidth does not match the viewport width. This property is supposed to return the width of the initial containing block, which has the same width as the layout viewport in desktop browsers. But in Safari in these specific scenarios, the property returns a number that is *larger* than the viewport width.

So in order to prevent infinite loops, Safari implements some weird behaviors that could be considered bugs. If Apple does not want to align with other browsers and the CSS spec, then you should at least document Safari’s behavior, so that developers have an easier time understanding it. This is of course if Safari behaves as intended.

[John Wilander]

Thanks! We'll have a look at this. And obviously sorry for the long delay.