|Viewport width incorrect when scrollbars present and overflow is not auto|
|Reported by patrick....@gmail.com, May 26 2014||Back to list|
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36 Steps to reproduce the problem: 1. Set overflow to anything except auto on html. 2. Create an element (A) with a width 100%. 3. Create an element (B) with a width 100vw. 4. Elements A and B should have the same width but element B is wider by the width of the scrollbar. What is the expected behavior? Elements A and B should have the same width since overflow is not "auto" on the root element. What went wrong? According to the CSS Values spec (http://dev.w3.org/csswg/css-values/#viewport-relative-lengths) "vw" should be affected by the presence of scrollbars but that scrollbars are assumed not to exist is overflow is "auto" on the root element. By setting the overflow on the root element to "scroll" I would expect that with width of my elements would match since the width of the scrollbar would no longer be included in the viewport width. In Firefox 29 this works as expected. In IE 11 it does not work as expected. In Safari 7.0.3 it does not work as expected. Did this work before? N/A Chrome version: 35.0.1916.114 Channel: stable OS Version: OS X 10.9.2 Flash Version: Shockwave Flash 13.0 r0
May 26 2014,
Forgot to mention that if you want to reproduce this properly on OS X you must set scrollbars to always show. http://osxdaily.com/2011/08/03/show-scroll-bars-mac-os-x-lion/
May 26 2014,
patrick.arlt,thanks for filing the issue.When i am trying to run the mentioned HTML file in the reported chrome version ,could not find any elements or attributes in the page,same with firefox.(please find screen shot. Can you please re-send the HTML file again ? Note : Thanks in Advance.
May 26 2014,
I've attached a new version of the file with some better labels. You also have to set scrollbars to always show to reproduce this properly http://osxdaily.com/2011/08/03/show-scroll-bars-mac-os-x-lion/ shows the appropriate setting.
Sep 23 2014,
Tim, could you take a look?
Oct 26 2014,
This is an upstream issue with Webkit. See here: https://bugs.webkit.org/show_bug.cgi?id=133271
Oct 27 2014,
Chromium uses Blink (forked from WebKit) as its rendering engine so thing is actually a Chromium/Blink issue not a WebKit issue. Safari still has the bug and does use Webkit though.
Jun 24 2015,
Sep 29 2015,
The issue occurs on a Mac, depending on whether "always show scrollbars" is on in the system preferences. This should really be fixed, as this is making the vw units pretty useless.
Oct 12 2015,
Issue 536793 has been merged into this issue.
Dec 22 2015,
Seems fixed on Mac El Capitan tested on both FF and Chrome stable. Both produced the same result. Also set scrollbars to always show to reproduce as suggested in C#3. Marking as WontFix - please comment here if that needs to be reversed. Thanks!
Feb 24 2016,
This bug still exists in Chrome 48.0.2564.116 m (64-bit) on Windows.
Mar 1 2016,
On Chrome 49.0.2623.54 beta and OSX 10.11.3 (El Capitan) the bug still there
Mar 1 2016,
Sep 23 2016,
I'm building a layout that uses columns that add up to 100vw, plugging in a mouse breaks my layout. That shouldn't happen. Is this issue likely to be picked up by anyone?
Feb 12 2017,
Apr 6 2017,
Same issue. 100vw seems to count the width of the scrollbars, which makes it fairly useless.
Having the same issue. According to the VW spec, when overflow properties are set to scroll it should deduct the scrollbar width from the VW but currently this does not work properly in latest version of Chrome.
after some more tests, it seems only to happen on Chrome on Mac with the General system preference of Show scroll bars set to Automatically based on mouse or trackpad. I am using a wired non-touch/non-trackpad mouse with an old fashioned scrollwheel. When I use a wireless apple mouse with touch-scrolling, with the same system preference, the VW is calculated correctly as the scrollbar become a transparent overlaying one.
Note https://github.com/w3c/csswg-drafts/issues/1766, which means this should probably be WontFixed.
Yup, you are right! :) Closing as per: https://github.com/w3c/csswg-drafts/commit/c1c2e82ca98a5a88f811e9d165757136d33f9dd4#diff-c3798e248ee6e7eeb80c7b12f053a5deR1009
|► Sign in to add a comment|