Strange JavaScript errors in IE9 - javascript

We have a website (asp.net, C# 3.5, Ajax Control Toolkit 3.5, jQuery 1.3.2) it is working fine in IE8 (also OK in Fire Fox and Google Chrome).
But our client asked us to make it IE9 compatible, when we tested it in IE9 it gives strange errors. Like SCRIPT5009: 'Function' is undefined', Array is undefine, object is undefined, means it says even native javascript object/functions are undefined.
Errors occur on those pages where there are IFrames embedded (good or bad but we can't remove IFrames from those pages).
After doing some R&D people said that IE9 has feature/bug related to IFrames (it was something like that if we change the position of IFrame in DOM after loading the page then IE9 re-initialize the IFrame to prevent memory leaks), we have IFrames inside Collapsible extenders of Ajax Control Toolkit, I don't think that expand/collapse extender changes the position of IFrame in the DOM instead of show/hide. But to overcome this what we did is that we deffered setting the src of IFrames until the page is rendered on client side and DOM is fully ready ( we used the pageLaod client side function of Ajax Control Toolkit) here we set the src of IFrames (don't know this was the right/wrong approach) but it works.
But now most of the time these errors don't occur but they still occur, some time when page is posted back.
Please help us to remove this error.

Related

JQuery Mobile and Firefox don't play well together?

Having some teething issues with jQuery Mobile. Was wondering if anybody else is experiencing a smattering of errors when they're using Firefox (desktop) and have the jQuery Mobile script includes in their <head> like so:
<script src="http://code.jquery.com/jquery-1.9.1.min.js"></script>
<script src="http://code.jquery.com/mobile/1.3.2/jquery.mobile-1.3.2.min.js"></script>
In both Chrome and Firefox I get a host of CSS errors, which I presume are negligible. But in Firefox I get a couple of JS errors on top of that, which also seems to break my page (responsive elements not rendering like they would when I remove the jQuery Mobile script).
The JS errors:
Empty string passed to getElementById(). # http://code.jquery.com/mobile/1.3.2/jquery.mobile-1.3.2.js:11100
Use of getPreventDefault() is deprecated. Use defaultPrevented instead. # http://code.jquery.com/jquery-1.9.1.js:3346
I know the errors seem pretty verbose, but I'm not familiar with bloaty javascript plugins and their policy on graceful degradation. Anyone else having this issue?
Update
As per Tim's answer, I've snapshotted evidence that these jQuery Mobile 'warnings' are actually effecting the page. Below is the page when I comment the jQuery Mobile script tags out:
And here is what the page looks like when the jQuery Mobile script tags are left in:
Note that the reason I wanted to use jQuery Mobile is purely for it's mobile touch/swipe events. I have no interest in adopting it's hash/ajax linking functionality.
What Firefox is giving you are warnings, not errors :)
Taking a look at the jQuery Mobile source :
// find present pages
var path = $.mobile.path,
$pages = $( ":jqmData(role='page'), :jqmData(role='dialog')" ),
hash = path.stripHash( path.stripQueryParams(path.parseLocation().hash) ),
hashPage = document.getElementById( hash );
Setting a breakpoint on that line using the Chrome Development Tools (Firefox and Firebug seemed unable to load the entire script), we can see that path.parseLocation().hash will be nothing when there is no hash in the URL, so document.getElementById( hash ) will throw the warning you saw in Firefox.
If it bothers you, you can turn off warnings in the Firefox Development Console, but if you're going to use jQuery Mobile I'm afraid the warning will be displayed for URL's with no hash. It isn't Firefox trying to tell you something IS wrong, it's just Firefox telling you something COULD be wrong, which is not true in this case.
Regarding the other warning, this discussion might be useful. It seems jQuery uses the deprecated getPreventDefault() for compatibility with Android 2.3.
Yes, jQuery Mobile does "mess with the DOM" when it's loaded. For example, jQuery Mobile will wrap your content in a "page" div:
Behind the scenes, the framework will inject the page wrapper if it's
not included in the markup because it's needed for managing pages
(Pages - jQuery Mobile Docs)
But you could see if it's the CSS or the Javascript that's breaking your site by including only one of the jQuery Mobile bits at a time.
I too am getting the same warning regarding the call to getElementById(), and I can confirm that it is just a warning and does not impact layout. I have asked specifically about getting rid this warning, but to no avail.
Finally, have you tried using jQuery Mobile's custom builder to get just the parts you are interested in (i.e. the touch features)?
My stuff often gets thrown out of format when using Firefox (many other small bugs too) If its just for testing, I suggest Google Chrome or Safari for best performance...

IE9 throws exceptions when loading scripts in iframe. Why?

Precondition:
I have an aspx-page with iframe inside. This iframe points to the url handled by MVC on the same site (it's hybrid site, both standard ASP.NET and ASP.NET MVC). The resulting page rendered by MVC contains a lot of scripts references.
Problem:
IE9 throws an exception on every single script it load in iframe. These exceptions are similar to this one:
Error: 'Function' is undefined
That is, it says that the most basic things every window has is somehow absent. Once you clicked through all of these popups, the page just works as designed!
If I load a URL from <iframe /> src attribute in the browser directly, everything works as expected.
If I open the page in another browser (I tried Opera, Firefox), everything works as expected -- no errors.
So, what IE9 wants?
There is this msdn page about this bug (or feature).
You get these kinds of errors when you move the iframe element around in DOM. In such cases, IE 9 garbage collects the iframe (causing your undefined bug) and reloads it at another position.
In general, you should create the element, set its src attribute only once and then put it somewhere in the DOM tree once. It has nothing to do with the code which runs in the iframe itself.
I have encountered this same situation in the wild. Basic symptoms:
You load script code in an iframe
The script code runs early (from the head section or top of body)
IE complains about some missing native object
I found that it can often be prevented by delaying the execution of the script code until onload or DOMContentLoaded... Not much help I know but this is one of the most difficult IE scripting bugs I have ever encountered. I upped the score of your question, hope it will be found by others as well and we can get a more detailed answer.
Also see this question:
Error in Internet Explorer 9 (not earlier versions or other browsers) when including jQuery in an iframe
Placing the following script block at the very top of the iFrame html <head> seems to resolve the issue in my case. Basically, it forces the iframe to reload, which as some have pointed out, solves the issue. It seems relatively safe, because, without things like 'Object' and 'Date', javascript is essentially useless.
<script type="text/javascript">
if(typeof(Object)==="undefined"){
window.location.reload();
}
</script>
Try loading the javascript at the end after complete web page is loaded. I feel the script is executing even before the iframe is completely loaded.
for some suggestion of scripting in IE9 view the given link below
http://blogs.msdn.com/b/ie/archive/2010/06/25/enhanced-scripting-in-ie9-ecmascript-5-support-and-more.aspx
Further investigation revealed that the solution is to add the offending iframe to it's dom location BEFORE setting the 'src' attribute.
Once the 'src' has been set, changing location of the iframe within the DOM stack forces IE9 to garbage collect it.
Once 'src' has been set, iframe can be resized and changed via css positioning, but cannot change the relative location in the DOM stack.
Often times, plugins like dialogs and lightboxes will stuff an iframe with src already set into the dom, then append / prepend or whatever, triggering the GC to take place.
function waitForjQuery(){
if(typeof jQuery!='undefined'){
//Do yor stuff!
}
else{
setTimeout(function(){
waitForjQuery();
},500);
}
}
waitForjQuery();

FF - Iframe in contentEditable are not loading javascript

I'm currently trying to put together a rich text editor that includes widgets from a different location then the site the rich text editor is on. I'm doing this by providing an Iframe in the content area that is placed at the cursor.
Now the idea behind this instead of providing some kind of placeholder until they finish editing is so they can see what they are talking about while they type.
Now the iframe works perfectly fine in Chrome loads the content as expected, but in Firefox it seems to have disabled javascript in this case (notice none of the script files being downloaded), which is an issue as the widgets are extremely javascript heavy and don't function without it.
I have provided below a JSFiddle showcasing this issue, the site im loading in the iframe is just a javascript game but you will see it doesn't work in firefox but its okay in chrome!
http://jsfiddle.net/reefbarman/2uYja/2/
Any help is appreciated
Scripts won't be executed when designMode is activated (source). Internet explorer was the first browser to add this feature, and Mozilla implemented a similar function, heavily inspired by Microsoft.
Your code functions in Chrome, because Chrome has implemented designMode in a different way.
Well after some research and experimentation I was dealing with two different issues that looked like one.
Firstly I made a change to the rich text editor I was using to use contentEditable only as this seems to be the standard going forward and its a heavily html5 app im working on. So with designMode = 'Off'; the iframe would load in normal situations. But I had a strange issue where adding the iframe to soon after adding another element to the editable area caused the iframe not to load, so just delaying the add of the iframe by some time allowed that dynamically added iframe to load!
Problem solved!

IE7 excanvas -- $(document).ready() and IE7 creates problem

EDIT: I've identified a link to the below problem to the use of $(document).ready() instead of using the old fashioned onload attribute of the body
The problem
In IE7 the canvas/excanvas does not render until you hit reload -- I've cleared my cache multiple times, and the result is consistent.
The canvas is always empty on initial page load, and an error comes up "object does not support this property or method" -- a message that refers to the .getcontext() call. However, once I hit reload, it magically works. Always after a reload.. it works. never by any other means of reaching the page does it work. There is always an error on initial page load.
By "initial page load" i mean when the page loads from a clicked link, a manual entry to the address bar or via the back/forward buttons.
Here's a reproduction:
http://www.trevorsimonton.com/canvas_problem/example7.html
Note that there's a lot of extra Javascript in there to reproduce the Drupal environment where this problem originated.
The code
I am using excanvas r3 -- http://code.google.com/p/explorercanvas/downloads/detail?name=excanvas_r3.zip and Drupal 6
EDIT: I removed a bunch of the code I had, because I have 2 places on the site where I am handling canvases completely differently. I was able to reproduce the problem at the destination above (http://www.trevorsimonton.com/canvas_problem/example7.html)
The root of the question
Does anyone know more about how excanvas or IE7's behavior that might trigger this kind of issue? What, aside from the browser's cache, could be causing the page to load differently between a "reload" command and anything else?
Because this is Drupal 6 I'm using Jquery 1.3.2
Apparently $(document).ready() fires before excanvas is really ready. Although that's not the case in most browsers, of course IE is going to be different.
IE7 needs all calls to getContext() to originate from a function passed into the body tag's onready attribute.
Do do this in drupal is a little tricky, but I just hard coded it into the page template.
See this if you want the full how-to: excanvas and JQuery 1.3.2 document ready don't get along

Javascript in IE8 very slow, IE7 + others fast using jQuery, jQuery UI, nyroModal

The page is rendered within an nyroModal (loaded via ajax) and the DOM is manipulated quite a bit using several plugins before actually showing the page.
Everything is fine in non-IE-Browsers and IE7, but in IE8 the resizable and draggable of an div is very slow and crawles along.
I know IE8 is slow. I know my DOM is big. I know i use a lot of plugins. My question is, what exactly slows it down, as other Browsers do it well?
I deactivated every plugin after each other to locate the culprit. Only having resizable activated it is still slow.
I used IE8 profiler and it says offset uses most of the time.
EDIT: I analyzed the page using dynaTrace AJAX Edition and it showes me that these 2 functions are responsible for the most exec time:
jQuery.fn.offset = function(options)
and
jQuery.expr.filters.hidden = function(elem)
both in jquery.js
i read somewhere that IE8 has problems with offset, but how can i circumvent this?
Edit2: I builded a test-page with just a link to open the page with all the resizing in a modal. works nice also in ie8 ! so i guess the big DOM of the modal-parent-page is the problem.
any advice appreciated!
Dynatrace has a very good javascript profiler. Check it out.
Check that your browser is not running in IE7 emulation mode.

Categories