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
Related
I'm working on a Drupal 7 site, the mobile version of the site which uses Bootsrap as theme.
There is a custom block (created w/ drupal) using jQuery to move some elements on a page, changing some classes and IDs. This block works just fine.
My problem is in a custom module which renders a block. I have some jQuery code in the module's template that is not running on refresh in Safari, but it runs if I go on the address bar and hit "Go" on the keyboard.
edit: IE and Chrome seem to also have a problem, but the jQuery code runs sometimes, doesn't matter if is a refresh, clear cache or whatever.
Nothing special in browser's console.
My jQuery code is supposed to move some elements in the page, on jQuery(document).ready, but is not even working for a simple alert.
p.s.: the jQuery in my custom module's template doesn't have anything to do with the code or the HTML elements affected by the custom block, but I thought maybe it would be good to mention it.
I hope you can understand the issue :)
Thanks.
I was using jQuery(document).ready to execute my code. I changed to jQuery(window).load and now it works fine. The code executes on first page load and on every refresh.
After like two weeks and almost killing myself, this is only thing that worked for ios safari.
$(window).on('load', function () {
setTimeout(() => {
DoLoad();
}, 180);
});
I had a similar problem and tried probably a dozen or more ways to address an issue with Safari. It looks like Safari triggers $(window).on('load',...) jQuery call before DOM completely builds. Or perhaps there is some kind of timing/racing condition. In my case, it was causing an issue, but only after page reloads, only with Safari, and only with a certain cloud provider. Chrome was fine, on prem hosting was fine. The only way which worked somewhat reliably was to introduce an artificial delay via setTimeout() function.
$(window).on('load', function () {
setTimeout(() => {
$.getScript('{{url}}').done(function(){
$("#element").js_function({
arguments
});
});
}, 360);
});
This answer https://stackoverflow.com/a/10929430/749227
to this question Is possible to debug dynamic loading JavaScript by some debugger like WebKit, FireBug or IE8 Developer Tool? is spot on for debugging dynamic scripts.
The issue I am facing is that I have a page that has a script on it, and after it loads an ajax request fires which returns with some HTML and a script that get put into the page. With the //# sourceURL=myDynamicDocumentFragment.html bit added, I can debug the dynamic script just fine.
But once it's loaded, then the other script that is part of the outer page that initially loaded goes off the rails. I can set breakpoints on blank lines and can't set them on legitimate lines. The debugger will stop on them but it won't be at the place in the code where I'd expect.
What it appears to be is that the dev tools window is showing the original script, and the debugger itself is running on something else - some updated version of code that includes both the outer page's script and the dynamic script that was added later. Or maybe it just hiccups with respect to line numbers it's displaying and what those map to in the code it's actually running.
I wish I had a good simple code snippet to demonstrate the issue, but I don't. Has anyone seen this, and does anyone know of a way to have Chrome 'refresh' the dev tools scripts/debugger without refreshing the page? (it has to be w/o refreshing the page since things work fine when the page loads - it's only after the dynamic script is dropped in that the wheels come off)
Note: I've tagged with Chrome since that's what I'm using (v 38). I don't know how other browsers fare.
You can find scripts injected into head or evaluated, here is a break point added on youtube evaluated (another js file).
You can find this in chrome as well, adding console.log (click on message shown), and voila you have source code you can add break points.
Here mozila print debugging/breakpoint over evaluated script on utube page:
Update
Sorry, I understand chrome was out of the scope, my engrish :)
How I did debugging on chrome over injected scripts, but there are cases when you cannot attach to execution if script is active (page load plus few milliseconds), you need to search for workarounds.
Added this at the begin of the script injected:
//# sourceURL=jseinjectedsource.js
console.log("evaluated");
and voila console:
Better check this way better than my explanation chrome developer
Check to see if your script is using a source map (if you're using TypeScript this is typically on by default for VS projects).
I've found Chrome to be really bad with source maps, often refusing to update them, or stop displaying them after the source map line is removed from the code.
I have used some jquery components in my web site, Suddenly i'm getting an error,
"A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete.
"
I have used, Jquery tab component, Carousel components 5 times, image slider component. Is it due to many Jquery compnents?
I have used,
jquery-1.6.4.min.js
Fixed the error,
Issue was the order of some jquery scripts. Once its in the correct order, it works without any issue, not due to too many components.
#madhairsilence and #pst - Thanks for the comments
Problem in Firefox,
Disable firefox add on and restart firefox with safe mode...
https://support.mozilla.org/en-US/questions/1008123
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();
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.