Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
css() reports wrong width/height in Chrome on certain zoom levels #3808
jQuery 3.2.1 reports wrong sizes for elements with
In the provided test case, we have two <div>s with 10px padding on all sides, 1px border on all sides and a CSS width/height set to 32px. Because box-sizing is set to
If we now zoom to 110%, the numbers get slightly changed, probably due to some rounding errors (31.9886px instead of 32px). Because we should always get "CSS pixels" that are not affected by browser zoom, I would have expected those numbers to stay the same - but I can live with that. The real problem occurs when you reload the page while having the browser zoom at 110%! Now the width is completely incorrect (53.977236000000005px instead of 32px).
If the page uses those values for programmatic layout, the results will be wrong. You can see the effect in the demo. The CSS width and height of the first <div> are copied to the second, so they should always be the same size. However, if you start at 100%, the second <div> is much larger.
Analysis has shown that this seems to be caused by the internal function
I could observe the problem at the following zoom levels: 110%, 90%, 80%, 67% and 33%.
Firefox (v56) and IE (v11) don't seem to be affected by this problem. Also, with jQuery 2.1.4, everything works fine on all browsers. All tests were performed on Windows 7 with default DPI and font size settings.
pushed a commit
Nov 24, 2017
pushed a commit
Nov 24, 2017
referenced this issue
Dec 4, 2017
Just to add to this, I reported this (or a very similar issue back in May) and was essentially told that browser zoom is not supported and I should essentially expect things to break around it between versions. Has the policy changed?
In the end I had to rip the code out that was using jQuery and rewrite it, and also have not been able to rely on jQuery height/width for other parts as it may break with no intention of fixing it.
See #3681 for what I originally described as the issue
You didn't do anything wrong, but this particular issue was phrased in such a way and came with sufficient detail that it merited more attention. Even though both probably stemmed from similar underlying causes, this one highlighted a fundamental problem of our support tests failing with non-default zoom levels, which is more severe than any given response being wrong. And as @dmethvin noted, landing #3738 and #3656 changed things. We still can't guarantee behavior with non-default zoom, but as of f00a075 we have confidence that our browser behavior observations are correct (which is likely to resolve issues like #3681).
Our official policy remains "dimensions may be incorrect when the page is zoomed by the user", but we do try to make things work even outside of normal operating parameters if a fix can be achieved without incurring undue cost (factoring in all dimensions—file size, performance, code complexity, testability, maintenance burden, followup reports, etc.). I feel bad that you had to remove jQuery dimensions calls for your application, and hope that you will consider restoring them after 3.3 is released this month.
And please do report issues you encounter in the future. Our notices are caveats, not absolutes.