Okay, this is by far the weirdest bug I have ever encountered. It's pretty straightforward though. If I load jQuery and then jQuery mobile dynamically in any version of Internet Explorer, the actual IE window minimizes. This happens in all versions of IE through IETester, however, if I run the full version in IE9, it kicks compatibility mode and for some reason doesn't minimize.
I've tried various ways of loading the scripts (commented in the example code), all resulting in the same behaviour.
Why is this happening? Is there a way around it?
http://jsfiddle.net/Xeon06/RCsuH/
This is a known issue in jQuery mobile. The offending line is jquery.mobile.navigation.js:913.
// Kill the keyboard.
// XXX_jblas: We need to stop crawling the entire document to kill focus. Instead,
// we should be tracking focus with a live() handler so we already have
// the element in hand at this point.
// Wrap this in a try/catch block since IE9 throw "Unspecified error" if document.activeElement
// is undefined when we are in an IFrame.
try {
$( document.activeElement || "" ).add( "input:focus, textarea:focus, select:focus" ).blur();
} catch(e) {}
There's the call to blur() that's sending IE windows to the back of the stack.
As a workaround, you can avoid this by placing the script tags physically in the <head> of the HTML.
<!DOCTYPE HTML>
<html>
<head>
<link rel="stylesheet" href="http://code.jquery.com/mobile/latest/jquery.mobile.css" />
<script src="http://code.jquery.com/jquery-1.6.2.js"></script>
<script src="http://code.jquery.com/mobile/latest/jquery.mobile.js"></script>
...
Placing the script tags elsewhere in the document or inserting them via script triggers the bug.
This Fiddle demostrates the workaround in action. Note that this only works in a top-level document. If the document is in an <iframe>, the bug will still appear. Thus, if you open the JSFiddle editor in IE 7/8, it will still get sent to the back; but if you open just the rendered HTML, it will not.
My attempt at "fixing" it: http://jsfiddle.net/RCsuH/6/
#josh3736 was almost exactly right, somewhere in the code it is firing off a document.body.blur() which causes the minimization of the window.
My fix simply replaces that function with a no-op function. I was unable to get the script tags to fire an onload when they finished loading, so replacing the function (if necessary) is left up to you.
However all of this seems to be a bug in the jQuery Mobile library, and thus you should probably file a bug report with them. However, I'm not sure it will bother them too much that there is a bug on IE for a framework that is intended for mobile phones/tablets.
Note: This is horrible, horrible code that replaces native functions. If it is possible, don't use this.
Related
I've got a simple click handler that does something on the screen instead of visiting that link. Here's the code (I'm cutting out the nonsense but the important stuff is accurate):
Link Text
<script type="text/javascript" src="./path/to/jquery.js"></script>
<script type="text/javascript">
$('#others').on('click', function(ev){
ev.preventDefault();
ev.stopPropagation();
// Doing stuff (some simple DOM manipulation)
return false;
});
</script>
This works fine on proper browsers. It works fine on Android (both older webkit and newer Chrome builds) and it works fine on iOS on the iPad 2... But one of my users is using an iPhone 4 and that's where all the fun starts.
When they click the link, the link loads. Despite three separate triggers not to, the event is still firing. Other javascript is working on the page and as I say, this is working everywhere else. Actually to confuse things a little more, the event is suppressed very, very occasionally. Less than 1% of the time.
So is this a known issue with iPhones? Is there a better way of doing all this?
The javascript is loaded at the end of the body (still inside it, but after all the DOM elements it mentions). jQuery version is 1.10.1
try using href="javascript:void();"
Link Text
$('#others').on('click', function(ev){
//ev.preventDefault();
//ev.stopPropagation();
// Doing stuff (some simple DOM manipulation)
return false;
});
So in my JavaScript app I am doing some dynamic script injection etc during runtime. Like appending script tags to the head of my document post page on load.
It seems fine if I go directly to the URL of the page through the navigation bar but when I do a right click refresh, IE seems to ignore any or all of my script tag injections.
Has anyone else seen this problem of have suggestions?
Don't see this in Chrome, FF, Safari.
I am using requireJS to do the injection if that makes a difference, but since it just does a document.createElement("script") etc. shouldn't make a difference.
Looks like the problem has actually that I am dependent on the load event ... IE / jQuery seem to be buggy in regards to maintaining the proper execution of onload for window. Using a timeout as a backup to dynamically inject the JS.
You might want to try disabling the use of the cache on those pages. See this: http://www.htmlgoodies.com/beyond/reference/article.php/3472881/So-You-Dont-Want-To-Cache-Huh.htm
According to the article above, one method you could use to disable use of cache is to put
<HEAD>
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
</HEAD>
at the END of the page
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();
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
I'm using an image cross-fading method via jQuery on a website. For confidentiality reasons, I can't post the site's entire code, but here's the Javascript for the cross-fader (based on this reference):
<script type="text/javascript">
$(function () {
if ($.browser.msie && $.browser.version < 7) return;
$('#nav li')
.removeClass('highlight').find('a').append('<span class="hover" />').each(function () {
var $span = $('> span.hover', this).css('opacity', 0);
$(this).hover(function () {
$span.stop().fadeTo(250, 1);
}, function () {
$span.stop().fadeTo(250, 0);
});
});
});
</script>
It works swimmingly on all browsers -- including the IE7 install on my test PC. However, on other PCs with IE7, the effect sometimes fails. The images will load, but hovering over them produces no effect. This means the JS isn't outright failing -- in that case, the rollovers would still work, just with no fading. Instead, it seems that IE7 is removing the "highlight" class, but then stopping.
The truly bizarre part? The failure is 100% random. If I refresh the window, sometimes the effect will work fine. How can this be?
UPDATE: I've determined that the problem lies somewhere with the AJAX scripting that's powering the website. Removing all AJAX and replacing it with static content eliminates the error. My theory is that when the page loads, sometimes the AJAX content is completed before the image load. This makes IE7 freak out and give up on the crossfade effect. If I'm correct that this is the problem, the question is: how can I fix it?
UPDATE 2: Going further down the rabbit hole, using Fiddler, I notice one consistent thing for each successful load of the effect in IE7: the loading of the main image that I'm using for the hover is aborted, then loaded again. This does not happen when the effect is unsuccessful. To put it another way, forcing the browser to preload the images using a simple jQuery preloader function breaks the cross effect in IE7 every single time, instead of its current sporadically-working state.
This is just too bizarre for me to even comprehend, but any ideas are certainly welcome.
Is your CSS included before you call the ready function? From the docs:
Note: Please make sure that all stylesheets are included before your scripts (especially those that call the ready function). Doing so will make sure that all element properties are correctly defined before jQuery code begins executing. Failure to do this will cause sporadic problems, especially on WebKit-based browsers such as Safari.
I understand IE is not WebKit based, but it's worth checking.