I have a timer in Javascript that fires once per second to update some text in the page (HTML5) like this:
document.getElementById('CountDown').innerHTML = "some string";
This works fine except that if this code runs while the user is dragging a scrollbar handle the drag is aborted. This is a very annoying user interface behavior which I have not been able to resolve.
If I comment out the line in the timer event then the scrollbar works normally.
Note: It only happens on Chrome, not on Firefox or Opera.
Any idea how to address this?
The smooth scrolling is a very important and effective function to enhance the user experience, it looks like there are several cases like yours concerning the smooth scroll in the chrome browser, and how it's not working properly, but the issues are in must of time related with the older version, like:
https://github.com/simov/simplr-smoothscroll/issues/27
https://github.com/mathiasbynens/jquery-smooth-scrolling/issues/1
https://github.com/iamdustan/smoothscroll/issues/28
You could try the following rules in your CSS:
html, body {
overflow: hidden,
height: 100%
}
And for your container you could attach the following rules:
{
overflow: auto;
height: 100%
}
Instead, since the code work in the other browser means that your code is valid, so just make sure you're using one of the latest versions, clear your cache & give it a try.
Probably not the answer you want to hear but I had this problem several months ago, there are several known bugs with the smooth scrolling feature of chrome when javascript is updating the DOM.
The newer versions of Chrome seem to handle this much better. I did a quick test where the code is similar to yours on the latest version of Chrome, and there were no problems.
It seems unlikely that there is an error in your code if it is working well in other browsers. Might be best suggesting users to ensure Chrome is fully updated for the best experience on the website or to use another browser.
Seems to be OK now - after release of Chrome 68.0.3440
Related
I have an issue with Firefox. In both responsive mode and Firefox Mobile to be accurate.
The touch scrolling isn't working on my website. (But the scroll with the mouse is working on Responsive mode)
It works fine on Chrome mobile & Safari mobile.
I checked online and I already tried the dom.w3c_touch_events.enabled set to 1. It was actually set to 1 by default.
I think it's an issue on the JS/CSS side but I can't see where.
I use SASS and Pleeease to compile it and it's a React app compiled with webpack.
Also I use the method fetch to call my webservices if it can have any influence but I doubt it. (and have a polyfill for it)
I tried to nuke totally my CSS and it still didn't work.
Happy to share URL if people want to see the actual problem. I just don't want to be seen as a spam. Also I will share a test server and not the live one. (problem is the same anyway)
Found the (stupid) solution and posting it as it might be helpful to someone.
I had a overflow:hidden; added by mistake in html, body { into my SASS.
For some reason the responsive mode in Firefox is still not working (bug? cache? I don't know...). But once I tried again on my Firefox mobile it was gone.
Looks like Chrome and Safari are ignoring this CSS but not Firefox.
For the record I am on last versions on all my browsers.
I've noticed that my events trigger differently in Chrome vs. Safari. Firefox (largely) acts the same as Chrome. However I've somehow stumbled across the fact that Chrome and Safari seem to load or execute JS at different times. For example, code that works 100% on Chrome will not work in Safari because Chrome calculates the height of a div (for example) after the page is loaded and Safari does it before. Or, at least I think that's the issue.
...
$(window).on('load', function() {
$('.menu-feature-wrapper').each(function(){
menuHeight = $(this).outerHeight();
$(this).find('.col-md-4').css('height', menuHeight);
});
});
...
In this example snippet - with about 200 additional lines of JS above and below, I had to wrap the working Chrome code (which is all wrapped in $(document).ready of course) with $(window).on('load'... to make it calculate the heights properly in Safari, even though it was acting as expected in Chrome.
My question is this: what's the deal with javascript between Chrome and Safari? Should I just be aware that certain events need to be executed after the entirety of the page loads and that Safari will expect that? Do they actually load JS at different times, regardless of where I include them in the DOM (header vs. footer)? Further, is there some place that explains this? I may just be bad at the Google, but I found very sparse information on how JavaScript is treated between Safari and Chrome, and all other browsers for that fact.
Thanks in advance for pointers/links!
What are some tool to help uncover why for instance FF is rendering a page differently than chrome ie and safari. My issue is simply the images along the left side of my main body get stretched to the length of the page only in FF every other browser renders in perfectly!
If anyone cares to see the difference
http://tinyurl.com/7vkcvn5
Works in everything but FF
I sometimes have luck running a page that is exhibiting quirks through a validator just to check that there isn't a typo or something triggering the problem. Try http://validator.w3c.org/. Your page has many validation errors in it, so that could explain the rendering quirks. (Some people argue, correctly in my opinion, that in some situations validation errors are OK. This doesn't strike me as one of those situations.)
Might not answer your specific alignment issue, but for differences in browser support, I usually go to http://quirksmode.org/ and http://caniuse.com/. To find polyfills to patch over browser differences, I usually go to http://html5please.com/.
browserstack.com
and
spoon.net/browsers
are two of the best tools I have been using.
Problem: A div with visibility:visible inside a parent div with position:fixed and visibility:hidden causes rendering problems in Google Chrome. Images and examples can be found here.
A week ago you could just add the -webkit-transform:translateZ(0) to the parent div and bug solved. But it isn't working anymore:
Without -webkit-transform
With the hack.
Both are bugged.
So, is there any solution? When you resize the window, it repaints the divs, also when you open the developer tools the bug disappears.
So I've been trying to force a repaint with javascript (jQuery):
jQuery(window).scroll( function() {
jQuery("#parentDiv").addClass("nothing");
jQuery("#parentDiv").removeClass("nothing");
});
And it sometimes works (when a textfield is displayed inside the inner div). Really weird. Also tried hiding and displaying the div, adding css properties (fixed, bottom:0...)
But nothing works fine.
Any ideas?
EDIT2: Seems like it only happens to me: 2 friends, using windows and the latest version (17.0.963.79) don't see the bug in the second link. But I still see it. I've reinstalled chrome under windows, and the bug is still there.
I also have cleared the cache, but nothing changes. Am I the only one????
from my own experience when working with scroll(), all form-elements behave strangely, or do not function anymore.
You solution -webkit-transform:translateZ(0) will fix it for webkit browsers, but all others browsers will trow a translated layer above all form-elements, result is that form-element are not accessible anymore.
scroll() is a great solution for just plain info (text- images), not for forms.
I'm using a javascript script called ImageFlow. It runs fine in FF/Chrome, however is very slow and hangy.
In IE (9,8,7) it just refuses to load at all. There are no JS problems, and I can't post the code as there is too much and I also didnt code any of the site so dont know what triggered it to go wrong.
The demo site is http://crofts.propertylogic.net and the JS for the imageflow can be found at http://crofts.propertylogic.net/coverflow/imageflow.js . The effect is meant to slot into the white box in the middle of the page, with the team members, as you can see on chrome/ff. If anyone could point me in the right direction that would be great.
I can't fix the code for you, but I can tell you basically why it isn't working in IE9. The init event that finds the 'myImageFlow' div is happening before that div has been read into the DOM. I believe it's because of the way the ImageFlow plugin imitates the DOMContentLoaded event for IE. The ImageFlow plugin uses the DOMContentLoaded plugin which hasn't been updated since May '08. I would bet you that library is out of date and as a result it is breaking ImageFlow, which also looks to be quite out of date.
I would honestly suggest that you look for a more modern plugin. If that doesn't help, try messing around with the DOMContentLoaded section to see if you can figure out why it is not delaying long enough in IE9 (use the debugger F12).
If you didn't code any of the site, chances are you didn't install imageflow at the site either. But installation has been covered, right? Or maybe not!
http://finnrudolph.de/ImageFlow/Installation
<div id="unique_name" class="imageflow">
<img src="dir/image_1.jpg" longdesc="URL_1" width="w_1" height="h_1" alt="Text_1" />
</div>
The image width and height parameters (w_x and h_x) must be set in the XHTML for full compatibility with the Internet Explorer. Sorry for
this extra load of work - every browser but Microsofts Internet
Explorer can fetch the right image dimensions via the JavaScript!
That means would you have to insert the image dimensions into the xhtml at server side for ie I think. Is that currently being done?
Checked the website on IE8 and seems to be working fine with animation bit, only things i the Images looks stretched vertically.
you can fix this using jQuery - all are correct the dom handler is the issue.
$(document).ready() is the key
$(document).ready(function()
{
var circular_3 = new ImageFlow();
circular_3.init({ ImageFlowID: 'imageflow1',
//circular: true,
reflections: false,
reflectionP: 0.4,
slider: false,
captions: false,
opacity: true,
xStep: 250,
imageFocusM: 1.5,
startID: 2
});
I know this is a little late to answer this question. InvisibleBacon is correct in that the domReady code hasn't been modified since 2008, but I checked the domReady code and it does work for IE 5 through 11, Firefox, Chrome, Mobil Chrome, Safari, and Mobile Safari. I did not check the code with Opera.
In this case I would say the problem is with the imageflow.js code you were using, which I see you no longer use.