0.6.0
NA, however it is happening on a 4k monitor
16.04.2 LTS
npm run testExpect the tests to pass
The console complains with the following:
Chrome 56.0.2924 (Linux 0.0.0) MDCSimpleMenu adapter#getAnchorDimensions returns the dimensions of the anchor container FAILED
AssertionError: expected 20.99609375 to equal 21
at Context.<anonymous> (webpack:///test/unit/mdc-menu/mdc-simple-menu.test.js:311:9 <- test/unit/index.js:16729:16)
I have not been able to reproduce the issue on any computer that has monitor specs similar to a Macbook Pro's retina display or lower.
Looks like this is an issue with how high-resolution monitors return values for getBoundingClientRect(). The fix is relatively straightforward:
assert.equal to assert.closeTo. The delta param should be .1/.2.Was able to reproduce the bug by running Chrome with --force-device-scale-factor flag with a fractional value:
diff --git a/karma.conf.js b/karma.conf.js
index f094b67..6eb0447 100644
--- a/karma.conf.js
+++ b/karma.conf.js
@@ -21,6 +21,10 @@ const USING_TRAVISCI = Boolean(process.env.TRAVIS);
const USING_SL = Boolean(process.env.SAUCE_USERNAME && process.env.SAUCE_ACCESS_KEY);
const SL_LAUNCHERS = {
+ 'chrome-device-scale': {
+ base: 'Chrome',
+ flags: ['--force-device-scale-factor=1.33'],
+ },
'sl-chrome-stable': {
base: 'SauceLabs',
browserName: 'chrome',
@@ -165,5 +169,5 @@ module.exports = function(config) {
};
function determineBrowsers() {
- return USING_SL ? Object.keys(SL_LAUNCHERS) : ['Chrome'];
+ return USING_SL ? Object.keys(SL_LAUNCHERS) : ['chrome-device-scale'];
}
Getting exactly the same error:
Chrome 56.0.2924 (Windows 10 0.0.0) MDCSimpleMenu adapter#getAnchorDimensions returns the dimensions of the anchor container FAILED
AssertionError: expected 20.9938907623291 to equal 21
at Context.<anonymous> (webpack:///test/unit/mdc-menu/mdc-simple-menu.test.js:311:9 <- test/unit/index.js:15487:16)
@amsheehan, you probably will be able to choose some --force-device-scale-factor value which will prevent the test from failing. Most likely --force-device-scale-factor=1 will solve the problem.
@anton-kachurin that's super interesting re --force-device-scale-factor. I wonder if this is something we should enforce? However, this is something that other browsers may not expose as a configurable parameter.
@traviskaufman do you mean to enforce it for all local tests on every developer's machine? Doubt that it's reasonable. I'm using a high DPI screen too, and test are passing just fine on standard settings. It was pretty difficult to make it not working.
I think in this particular case only the assert.closeTo fix must be applied.
Btw, another way to break the tests is to wait for the moment when the browser opens and then quickly zoom the page down to 67%. This potentially means that not only the tests but some future components may be buggy on zoomed pages or high DPI screens.
This brings me to the idea that developers should be aware of high DPI/zoomed pages quirks, therefore should be able to automatically test their components locally to detect those quirks.
A good addition to the test-kit may be a separate script in the package, such as npm run test:zoom, which will only run tests locally with the required flag and some knowingly glitchy value, e.g --force-device-scale-factor=3.1415. This will help to keep both unit tests and components bug free.
Bringing this back to address #1650. @amsheehan what monitor are you using? Just want to verify this is still an issue. If not I want to close the issue and the PR.
17" 4k display at 3840 x 2160 resolution
@abhiomkar, you tried to reproduce and weren't able to. I'm going to close this issue.
Most helpful comment
Was able to reproduce the bug by running Chrome with
--force-device-scale-factorflag with a fractional value:Getting exactly the same error:
@amsheehan, you probably will be able to choose some
--force-device-scale-factorvalue which will prevent the test from failing. Most likely--force-device-scale-factor=1will solve the problem.