I'm trying to set scrollTop property of some DOM element programmatically and I have weird behaviour that breaks my tests in some specific environment. I created minimal repro (the link)
HTML
<div id=viewport><div id=content></div></div>
CSS
#viewport {
overflow-y: auto;
height: 20px;
}
#content {
height: 150px;
}
JS
const viewport = document.getElementById("viewport");
viewport.scrollTop = 75;
console.log(viewport.scrollTop);
The result of the script is broken on Chrome 69.0.3497.100 running on Win 10 Pro. It is 74.4000015258789 instead of 75. It works properly on the same Chrome version on Mac and even on Win 10 Home running under VirtualBox. Firefox and Edge also have no such an issue.
I know it looks very strange, but what could it be? Can anyone confirm this problem? And could it be fixed in some way to make sure that the result of the scrollTop assignment is exactly I want it to be?
Update. Thanks to #khajjit, I was able to reproduce the issue on my Mac machine and got 74.66666412353516 on 75% zoom out and 150% zoom in. 80% gives 75, 90% -- 74.44444274902344, 110% -- 74.54545593261719 etc (I updated the demo to show the results table). So the issue does not relate to OS. But it looks like the Chrome only issue. Firefox and Edge return 75 at any scale.
Update 2. Scaling the screen resolution at the OS layer also affects the situation. That was the case of Win 10 Pro described above; it had 125% OS scaling.
So the practical part of the question is how to overcome Chrome scaling rounding issues to be able to set scrollTop precisely?
Update 3. Chromium Dev confirmed that this is a bug:
This issue is because Chrome does not fully support fractional scroll
offset.
So if someone is interested in this problem resolving, please follow the link and star the issue on the Chromium end.
I think it might be related to the resolution of the monitor.
I have a resolution of 1920x1080 and with a scale of 100% the result is 75.
But if you set 75% or 150%, the result will be 74.66666412353516.
Or say 25%, the result will be exactly 74.
I don't have any exact answer as to what it might be related to, but I think this little research might lead to the right path.
Related
In my HTML i have a <div> (call it the panel) with fixed width that contains some text; that text is set to font-size: 25px; line-height: 25px; in the accompanying CSS. It so happens that the text ends up as 36 lines.
Given that all margins, paddings and borders are zero, you'd expect the height of the panel to be 36 * 25px = 900px, and that is in fact what i find in Firefox, using the DOM's getBoundingClientRect() method.
However, in Google Chrome i get different figures; it would appear the panel is only 892.7999877929688px high while lines are 24.799999660915798px high. Dividing those two numbers still gives 36 though. It looks like there is a scaling ratio between nominal pixels as set in the CSS and real pixels as reported by getBoundingClientRect(); in my case, this is 1.0080645299120465 nominal per real pixels.
One more piece of evidence comes from Chromium running inside an nwjs app where i initially observed the discrepancy. During my tests, it showed consistently a different ratio from the one in Chrome. Now, at some point during my tests, the pixels reported by Chromium suddenly jumped to the integer values as reported in Firefox; i'm not sure what i did to make this happen.
It could be expected that the fractional ratios are in some way linked to page zoom; after all, at very small sizes, Chrome and Chromium reflow the text (and sometimes do it wrong). And indeed, varying the zoom in Chrome leads to different ratios, and making Chrome zoom in to the max will make the ratio flat out at 1. Still, my Chromium app is not zoomed in to the max and still has a fractional ratio. an integer pixels ratio in the test but a fractional value in the real app.
For all i presently know, all i can do to obtain the ratio so i can make sound, consistent box size measuring with JavaScript is to set up a box of known size and measure it.
I'm still wondering what the source of the observed behavior is. Are there any reports of it? Is it an intentional or an emergent behavior of the renderer? Was it ever discussed by the devs? Is there an API to obtain the ratio?
I've put some code on a gist at https://gist.github.com/loveencounterflow/d8c20b9021d2ab3f573a to simplify testing.
Some fonts cant be rendered at the exact size u ask for, and fonts had properties that affect indirectly to the real size reported. If you want same behavior everywere, maybe u have to import your own font to achieve similar rendering cross browsing. I had a similar problem while working on IE and Chrome.
Scroll through the images in Firefox (tested on v. 26) and you notice if you look to the right that the image stretches one pixel (or so) after its .src has been changed. This behaviour only occurs in Firefox and if the width of the image is increased or decreased by 1px (through web console), the behaviour disappears... I know that the image is bigger than the width I set but it still doesn't explain the behaviour and why it's only occuring at a very specific width (after all, image is still resized in browser if I increase or decrease the width by 1px as well but then the behaviour disappears). Works perfect in Opera, Chome, Safari and IE...
http://www.mosaikdesign.se/galleri_.php
Anyone?
I spent some time researching this and they way I see it, it's a bug.
I filed a bug report at Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=953364
I also made a thorough test page for those interested in studying this behaviour: http://www.blackwinged-angel.com/bugs/index.html
And finally, the fix:
-Set css property image-rendering on the image to something else than auto (optimizequality, optimizespeed, -moz-crisp-edges). It's claimed in the documentation that optimizequality and optimizespeed are the same as auto (https://developer.mozilla.org/en-US/docs/Web/CSS/image-rendering) but they do result in different downscaling algorithms being used (see my link for proof). However, this fixes the problem.
-Use image sizes where images are only upscaled, not scaled at all or check the resulting downscaling since it only applies to certain sizes of the containing element in relation to certain actual image sizes, not all.
Again folks, this only applies to Firefox, was tested on Firefox 26, applies to downscaling images on-the-fly in the browser by styling img (and possibly other) elements with width and height and it's not consistent (just happens at about roughly 30% of tested downscalings on a specific image for me).
I have some code where I add a canvas on the fly to a draggable, resizable div element. Its too much to paste here -->here is the jsFiddle...
It works fine in IE-10 and FF-19, but in webkit (Chrome-25) there are severe artifacts that get left behind when you drag the div AFTER doing a resize. Here is the test to run:
How to see the artifacts in WEBKIT BROWSERS ONLY
1. Drag the gray header, shake mouse, notice NO artifacts as you shake the div
2. Drop the header, resize div using the lower right handle so that you see about an equal amount of green and purple
3. Repeat step 1, only this time artifacts are everywhere in webkit browsers (not IE 10 or FF 19)
4. Now delete the javascript code from line 11 on down (the function and call) and run fiddle again
5. Repeat the test in steps 1-3. Without the canvas, there are NO artifacts.
6. Try in non-webkit browsers. NO artifacts.
The test case I constructed seems to point to the canvas being the culprit. I don't see this as a coding error since non-webkit works OK. Also, I thought maybe hardware was the issue but I have rebooted / run this on multiple machines and it is repeatable.
Have I found a browser bug, or does someone see an error in my code?
I had the same bug (and yes Sebas, I would call this a bug; better if you had a solution instead of just a critique).
The "overflow: hidden;" in your css is the trigger for the bug.
#wrapper {position: relative; width: 300px; height: 300px; background-color: silver;border: 6px solid lightgray; z-index: 2; border-radius: 15px; overflow: hidden;}
Here is a fork of your jsFiddle with it removed.
http://jsfiddle.net/sv9yZ/1/
I know this is old, figured I'd add this for anybody coming from a search...
I can repeat it in Chrome 25 on Mac OS X 10.8.2.
I've had problems with this before also. There seem to be bugs with the way the canvas drawing routines interact with CSS drawing. As it's a browser bug there isn't a nice way to fix this that I've found. I think all you can do is try hacks like cover the entire background with a div that you flash on and off when dragging to force a redraw. It's not pretty, but I've never found a nicer way to do this.
So my problem is fairly simple.
When I started to develop my website my default zoom level on my Firefox browser turned out to be, well, less than 100%. (Maybe 70%)
Which means that what I have designed so far is actually in zoomed out mode, which in turn means that my users or web visitors will see something that looks very zoomed in when they look at it with 100% mode.
This can easily be solved by holding Ctrl and scrolling you mouse wheel twice. Obviously though I can't encourage people to do that.
So,
Is there some function or property in either HTML, CSS or Javascript than can set the default zoom level to zoomed out?
I would highly recommend to create your website again !!!
Does it help ?
body { zoom: 3; -moz-transform: scale(3); -moz-transform-origin: 0 0}
Reference
Chrome can display initial zoom levels such as
HTML {
zoom:90%;
}
which would by itself zoom the entire page not the initial browser zoom level, this works like scaling, but it's not compatible with either firefox or safari or my guess. The rest of explorers.
GL
Nop, you can't. That's a browser feature.
EDIT: Firefox 2 windows XP
Steps to reproduce problem:
Firefox 2 and visit: http://resopollution.com/rentfox/html/property_setup.html
Begin Typing and pressing [enter key] to create new lines
After about 10 [enter key] presses you'll notice the screen shaking
How this happened
This began happening after I installed a plugin for jQuery. It's located here:
http://resopollution.com/rentfox/html//js/textarea.js
It makes it so the textarea is expandable as I type, depending on how many lines there are in the text area, up to a max-height value which can be specified in CSS.
I tried disabling the 'setHeight' function within this plugin (the only thing that changes height dynamically) but I still saw the screen shaking.
When I think the problem might be
Firefox thinks that the screen just got larger, and compensates by putting in a scrollbar on the right side of the body document.
However, it realizes that in fact the page didn't get larger, and removes the scrollbar, causing the shaking.
I have no idea where in the code that makes Firefox think this way...
Appreciate any help.
You can either force a scrollbar: http://css-tricks.com/eliminate-jumps-in-horizontal-centering-by-forcing-a-scroll-bar/
or hide the overflow of the div and try to get rid of the scrollbar, try overflow: hidden instead of auto in the div propertySetup
Can't reproduce, works fine here in Mac OSX + Firefox 3.5.
I can reproduce it (Debian Lenny, IceWeasel 3.0.6), but only with a very, very specific window size for FireFox (just slightly taller than 1024px, depending on your system font size, window manager and number of toolbars shown).
Just make your page slightly shorter or taller and the problem goes away. The problem only occurs when the addition of a new line after the 10th or so causes firefox to grown the page just enough to cause the scrollbar to appear. Just as you guessed.
That's a tiny 10px margin that is dependent on a lot of browser and system specific settings. In your page that margin is somewhere around the 1024px limit, depending on system font, toolbars, window decorations and the phase of the moon. Move that margin out of the 1024px region. Either make the page 40-50px shorter so that the scrollbar does not appear (even with large system fonts and an extra toolbar) or make it taller so the scrollbar is always there. Zoltan Lengyel's answer in this thread to always force the scrollbar can also be used.
I can reproduce it in Firefox 3.0.11 in Win XP.
Adding overflow:hidden to the body tag seemed to fix the problem, but doing that may wind up causing you more grief then disabling the plugin altogether. Giving the body tag overflow-x:scroll will stick a scrollbar there permanently but seems to solve it, too.
I reproduced it on Windows, FF3.
Interestingly it seems to happen within the jQuery .height() function!
Unfortunately you're using the minified version, so that's as far as I can get.