I'm using YUI,
and sometimes I'll see this "Permission denied to call method Location.toString" error,
It's reported in connection.js,
I didn't find any clue why this error occur yet.
Very strange
If you are dealing with any Flash through a cross-domain iframe, then it is quite possible that you are seeing a bug in Adobe's Flash Player that occurs with FF2 and FF3.
The bug is in Adobe's public JIRA here: http://bugs.adobe.com/jira/browse/FP-561
There seems to be no motivation to get it fixed, unfortunately.
If the script is executed from a different domain, or you are trying to access the contents of a frame/window/iframe of a different domain, you will see this error. Safari's behavior was a little different, at least in the v1-2 era (iirc), so you will probably want to test in that as well.
If you are including scripts via a different domain, you need to make sure your actual triggers/events are tied in and executed from inline scripts, or from a script file loaded from the same domain as your html for best results.
Hi I've answered a similar question
why/where the error “Permission denied for to call method Location.toString”.
This is caused by firebug showing errors from other windows in your console. In short, these errors will probably be nothing to do with your code at all.
If you want to test this theory, you can close all other windows in firebug, clear your console and test just your site.
Are you seeing this in Firebug, by any chance?
I'm getting the same thing in Firefox, off-and-on, after adding jQuery to my site. I'm calling the jQuery js from another site (different domain completely), which I figure isn't much different than calling it from Google's servers.
I have no code using jQuery at all as of the moment. And, while Firebug reports this as an error, it doesn't do so all the time. While I have it turned on, I'm seeing no errors in IE.
While there are different libraries involved, my guess is that Firebug is generating a false-positive.
Now if you're not using Firebug when you see this ... are you using YUI hosted on your own server? What browser are you using? Etcetera.
~James
Related
I'm a beginner web developer. I often use Firebug to debug my JavaScript.
Problem is that there are some script files from my page's UI that have a lot of code and this causes my web browser to be unresponsive, i.e. I get a dialog saying the script is unresponsive. Basically this happens when I am within Firebug's Script panel.
How can I deal with this?
I tried finding solution to this problem and nothing.
As for the answer I think the best was posted by #Pablo(can't assign answer to comment unfortunately) and it is simply trying out Google Chrome console. None of the problems I mentioned exists here.
Cheers guys!
I have had the same problem debugging some of our older scripts that make extensive use of the eval() function.
This causes many scripts to be displayed within the Script Location Menu. (Each dynamically generated script is represented there.)
A possible solution, given that it was caused by the number of files in my instance, might be to see if you can bypass the problem entirely by utilizing fewer source files for the same code. Using a 'built' version of whatever frameworks you use might alleviate the problem. (Particularly if they still are debug-able in a built form.)
If that does not work, you might try debugging using Firefox' built-in debugger (available via Ctrl+Shift+S. (Or switch to another browser to do the debugging, but that is obviously a far less desirable solution.)
I'm developing a jQuery mobile application. The application is developed in JavaScript, jQuery, and HTML. When I debug the application in browser using Firebug (in Firefox) it's working fine, but it doesn't run normally? Is there a reason it's running in debug mode only?
Your question is worded somewhat confusingly so I'm not quite sure what you mean but I think you might be running into a problem with console.XXX() statements in your JS - on a browser that doesn't have console defined (like IE) or a Firefox installation that doesn't have Firebug, console will be undefined and your JavaScript code is likely to fail if you have forgotten to comment out your logging statements. You can verify if that is the problem by commenting out all calls to console (or by watching the console and looking for log output).
A long term solution might be to define the console object when your JavaScript initially loads if it finds that the console doesn't exist - this way, even if you forget to comment out calls to console and someone who doesn't have Firebug installed or is using a different browser tries to use your code, they won't run into this issue. Take a look at this blog post
This question is extremely similar to the fully-updated version of the question asked here: How to call a JavaScript function from one frame to another in Chrome/Webkit with file protocol — unfortunately, that question was never actually answered.
I have an HTML page that contains an SVG image in an iframe. The SVG exports a JavaScript API that allows it to do useful things (reset to zoomed and centered, display at "actual size"). Below the iframe, I've put buttons that the user can click on that call through to the functions defined in the SVG.
My code looks like this:
function reset() {
document.getElementByID('iframe').contentWindow.reset();
}
It works perfectly in Safari, Firefox, and even IE 9 (which supports SVGs - hooray!). But on Chrome, it fails: the debugger informs me that:
Property 'reset' of object [object DOMWindow] is not a function.
And indeed, there does seem to be truth to that: even though 'contentWindow' is of type DOMWindow, it has no methods or fields (at least, not that the debugger will show me). Even asking for its 'document' field fails (yields null).
The rub appears to be the use of the file:// protocol to transfer both the containing HTML and the contained SVG. As noted in the question I referenced above, Chrome produces the following error when the attempt to access 'contentWindow' is made:
Attempt to access frame with URL file://[...]/contained.svg from frame with URL file://[...]/container.html. Domains, protocols and ports must match.
In general, I think security is great; this looks like a security-inspired restriction. But here, it seems to have gone too far: these are files on the user's filesystem, after all, and in my case, are even in the same directory.
Hosting the code is not an option - it must reside on the user's machine. I'd hate to have to tell people "just don't use Chrome - it has silly notions of security."
Is there no way to work around this restriction?
Of course there is no way :) These file protocols are meant to be explicitly called by the user. There is absolutely no way for a web application to allow that, as you have seen.
The only way to do that is if you "as a user" allowed that to happen, if so, you can enable that by adding the following command line parameter:
// By default, file:// URIs cannot read other file:// URIs. This is an
// override for developers who need the old behavior for testing.
--allow-file-access-from-files
So open up Chrome with: chrome.exe --allow-file-access-from-files this is used for development.
Thanks to the information offered by #Mohamed Mansour, I was able to find more details on this issue.
The rationale for Chrome's behavior is to prevent a maliciously-crafted page from, through JavaScript and internal frames, accessing the contents of your file system without your knowledge and upload data to the Internet [Chromium bug 4197, Chromium bug 47416].
It is unfortunate, from my point of view, that the Chromium team chose to take things as far as they did. Gecko is a bit more subtle in whacking this mole: it limits cross-page scripts to same-subdirectories [Mozilla bug 230606, Same-origin policy for file protocol]. The result is much less surprising for users and developers and has generated much, much less angst than has arisen over Chrome's behavior — read Chromium bug 47416 in particular to see what I mean.
Because of this behavior, I've had to modify my "website" — which cannot be hosted on the Internet and must reside on local-users' machines — so that it throws up a dialog box telling users to switch browsers. It's really too bad — I'd like to support Chrome but just can't expect my users to relaunch it with an obscure command-line option whenever they want to run my "website."
I'm posting my findings here in case anyone else stumbles across my question when Chrome seems to mysteriously not work for them and also to encourage anyone who reads this to consider starring Chromium bug 47416. The developers have made it painfully clear that they are unwilling to consider changing Chrome's behavior unless it's clear people really care about the issue. Being told "I've had to tell users not to use Chrome" hasn't been enough encouragement.
I haven't worked in JS since 1999, so I'm quite rusty. I remember working in it in the past, and I was able to enable some kind of error reporting. Right now, when I have a syntax error in a script, no error is reported in the browser. Is there a directive or something to enable error reporting in a JS file?
Most scripts in the wild are so full of crass errors that browsers don't bother complain about them any more.
In IE by default the error indicator in the left hand side of the status bar can be used to display the error. Or you can turn error alerts back on from Internet Options -> Advanced -> Browsing -> Display a notification about every script error, but that will make the rest of the internet unusably annoying.
In Firefox, Tools -> Error Console will bring back the familiar JavaScript console.
It's impossible to over-recommend the Firebug plugin for Firefox. It's become the de-facto standard for writing and debugging javascript. In the console panel of firebug, you'll find lots of errors and warnings you can toggle. In addition it allows inspecting dom elements, watching network timing, ajax calls, modifying html/css/and even adding code to live pages, in addition to a plugin system which allows a host of third-party utilities built on Firebug.
Browsers generally report errors in a non obtrusive way (probably because first JavaScript code written by amateurs was very buggy, plus end users (besides devs) don't know what to do with an error anyway).
Firebug for Firefox is great, and so is Web Inspector for Webkit. They both have a console you can print to using something like
console.log(str);
This is the page I'm working on... http://schnell.dreamhosters.com/folio/earthquake.html
Its purpose is explained via the instructions on the left. I'm finding that after doing so many searches and clicking so many of the links in the list on the right that the page freezes up, the Google Map stops working and Firebug tells me of an error in main.js and it goes like this...
b is undefined
Line 49
I really don't know why this decided to happen all of a sudden and the error is so cryptic and muddled amongst Google's code that I don't think I'll be able to figure this one out by myself.
Another problem I'm finding is that the page itself simply refuses to work in IE7 and IE8 (or probably any version of IE for that matter). I am also at a loss as to how to solve this problem because I can't figure out how to use any of IE's debuggers (if they even have one) and seeing how I already tested this and made it work in two browsers (technically three since Safari runs off WebKit just like Chrome), I just don't have the drive or capacity to imagine what could be going wrong.
Any help would be greatly appreciated
Moved from comment to answer.
As scunliffe mentioned, you are trying to do a crossbrowser AJAX without using jsonp. Use either $.ajax() with datatype jsonp or add a &callback=? at the end of the URL in the $.getJSON() call.
IE8 is quite good when it comes to helping out the developer. From memory F12 will open up the developer window where you can inspect the DOM, CSS and debug script.
Your error is cryptic because most javascript comes minified, so variables are all remapped to single letters, etc. See if the script causing the problem has a development (i.e. unminified) version as this will make a lot more sense to step through.
With regards to your specific issue it sounds like a timing issue. While browsers do a decent job of executing script in a consistent way if you follow standards, they do differ in their timings i.e. when things execute. That would explain why b is undefined in some cases and not others.