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!
Related
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
I have a website under development at Pragmatometer.com, and it seems to display perfectly, so far as I can tell, on Chrome, Safari, Opera, and Edge. Things are not equivalent with Firefox.
The page you will see if you visit the site looks different on Firefox from the others. The initial login screen on all the others is a stretched background via a jQuery plugin. Furthermore, if you create a login page on the other browsers, you will see widgets once you've logged in. On Firefox, it's essentially a white screen of death. Apart from a link at the top right that is directly present in the HTML, not built by ReactJS JavaScript, none of the four basic widgets display. Furthermore, I found nothing interesting in Firefox's debugger; there was a document.getElementById-related error, but it was not in my code and drilling down did not seem to cause anything to surface.
Are there issues with ReactJS and Firefox? I suspect something other and more, as the login screen doesn't use ReactJS and minimally uses jQuery for a background stretcher.
What should I know about developing for Firefox vs. developing with the others, now including Edge?
Thanks,
I'm loading 2 embedded svg-lets in a page. One animated one not. They're loaded in sequence with a setTimeout.
When I load the animated first all goes well, the animation starts as expected and the second static svg is correctly displayed afterwards. When I first load the second, and afterwards the animated one, the animation does not start.
Code is here: jsfiddle switch #svg1, and #svg2 in the javascript.
Upon browser checking I found out this is probably a webkit bug as chrome and safari both show this behavior FF 12 and Opera are well.
Can this be fixed with JS code or should I file a bug with webkit?
== Added
I think the question should be rephrased why the animation does not start after the svg is loaded with a settimeout.
As Jared investigated below it works when the element is present in the DOM and is reordered via dom manipulation into the focus element, Chrome and webkit need a kick with a beginElement() call to the animate element. This still doesn't work out for elements constructed from plain text. As I only do have a mac and I still consider this a hobby project I leave MS IE completely out of the loop.
Well, it took quite a bit longer than I anticipated, but I got it worked out. Basically, the method you were using with the semi-SVG and the regex on the markup, etc., was to say the least not quite the way to get it done.
The answer is to use svg DOM animation methods and attributes, especially to start/stop the animation when you want it to run. Apparently, Firefox was just fine with reinitializing the element and the animation just by manipulating the inner HTML/markup. Chrome (Webkit?), however, actually needs you to programmatically access and control the element. I have not checked in IE, Opera or Safari.
I redid the example, leaving out the arrow altogether, as it is unrelated to the problem. I instead concentrated on creating and testing the animation functionality. The critical points you were missing before were:
var $lasso = $('#lasso'),
animater = $lasso.find('animate')[0],
...
animater.beginElement();
...
animater.endElement();
Here is the demo I made, which is significantly different that what you have in your question:
http://jsfiddle.net/9hBfs/
What I call the "lasso" effect is still there, though.
I would reference the Mozilla Developer Network (MDN) site, as they have a lot of great information and are a highly trusted authority:
https://developer.mozilla.org/en/SVG
https://developer.mozilla.org/en/SVG/Element/animate
http://www.w3.org/TR/SVG11/animate.html#animation-mod
http://www.w3.org/TR/SVG11/animate.html#InterfaceElementTimeControl
http://www.w3.org/TR/SVG11/animate.html#RestartAttribute
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.
This question already has answers here:
How can I debug my JavaScript code? [closed]
(20 answers)
Closed 6 years ago.
I have some old javascript code from around 2000-2002 which (surprisingly) still works in IE, but doesn't in Firefox, Chrome, Opera etc. I already found out about some quirks, some browsers do some things this way, some another. So there are code snippets on the internet to create some browser plattform independent function that does it.
Now my problem is, to even locate the problems. Right now, there are buttons in the website, when I click them, something happens in IE, but Firefox does just nothing. There isn't even an errormsg. I tried stepping through the javascript Firebug, but at some point in the code, when I do the next debug step, the script just seems to abort, without any error message. It doesn't continue with the next statement. Pretty strange and I have no idea what causes it or how to fix it. :/
So how do I debug javascript so I get error messages telling me what the problem is, for example, what function/variable I'm using isn't defined in firefox or when I use wrong parameters.
Thx & Best regards
Marc
Firebug for firefox is okay. The console for safari and chrome, IMO, is better. In either case, right click the page, hit "inspect element," and click the "console" tab in the pane that pops up. Now you'll see any errors and warnings generated by the page.
If you really want to debug the scripts you can click on the "Scripts" tab and either pause execution immediately or set a break point. Then, you can step through the execution of the script line by line, inspecting the call stack and watch list as you go.
Firefox doesn't popup error messages or put them in the status bar (like IE). You have to open the Error Console to see the errors.
Firefox puts Javascript errors in the Error Console, but also HTML and CSS errors and warnings.
As to what might not work in the code, there are plenty of things that are IE specific and won't work in any other browser. Also there is a big difference between IE in quirks mode and IE in standards compliant mode. Put a proper doctype in the page so that it's rendered in standards compliant mode, which will make IE more like other browsers, and some IE-specific quirks are removed. This might cause your old script to stop working, in which case you know that it's likely that it's some IE-specific feature that causes the problem.
There's FireBug, but it only works for Firefox.
EDIT: Doh, you already mentioned this in your question.