On many pages including http://ajaxian.com/archives/some-more-javascript-performance-tips we get the message Permission denied to call method Location.toString We can't fix this problem because the error message does not give a line number, file name, what the caller is, what permission they need to succeed. The contents of the error object [category]=content javascript; [flags]=2; [sourceLine]=; [sourceName]=; [errorMessage]=Permission denied to call method Location.toString; [lineNumber]=0; [nsIScriptError.warningFlag]=1; [nsIScriptError.errorFlag]=0; [nsIScriptError.exceptionFlag]=2; [nsIScriptError.strictFlag]=4; [message]=[JavaScript Error: "Permission denied to call method Location.toString"]; [columnNumber]=0; See also http://code.google.com/p/fbug/issues/detail?id=692

I'm seeing this error message with this testcase, also with incorrect line number.

There should be a line number here ever since bug 246699 got fixed. John, was the comment 0 result with trunk? Note that on trunk loading the ajaxian.com page doesn't give the error for me. Comment 1 is the "no useful line numbers for attribute event handlers" thing.

(In reply to comment #2) > There should be a line number here ever since bug 246699 got fixed. John, was > the comment 0 result with trunk? Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 > Note that on trunk loading the ajaxian.com > page doesn't give the error for me. These seem to occur when Firebug is installed. > > Comment 1 is the "no useful line numbers for attribute event handlers" thing. > I'm not sure what you mean here Boris. I list browser generated event handlers in Firebug, getting their source from script decompile.

> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 > Firefox/3.0 That's physically impossible for comment 0, but I guess you mean that the error still does not have the information, right? Does the right line number appear in the error console if you don't catch the exception? shaver, can you think of a reason why calling JS_ReportError wouldn't give a filename/lineno to the resulting exception? > I'm not sure what you mean here Boris. Bug 11240.

If the script it was running didn't have filename/lineno info, there wouldn't be any in the report. A breakpoint in js_InitParseContext conditional on NULL filename or 0 lineno would perhaps help isolate the perfidy.

As far as i can tell comes this error from flash-ads (google) and even from pages where Firebug is disabled and shows up in Firebug enabled tabs.

Have a stack trace for it?

Sorry, i am a web-developer - how do i make a stack trace?

You could use windbg as per http://developer.mozilla.org/en/docs/How_to_get_a_stacktrace_with_WinDbg and set a breakpoint on js_ReportErrorAgain, but honestly it's probably a better use of your time to just come up with a reliable and minimal test case to attach to this bug. :)

From the ajaxian-page an (doubleclick) ad. No Error without flash-ad. If no flash-ad: reload. It seems to have something to do with the iframe. If the loaded markup is rendered in a full/normal frame (http://ad.doubleclick.net/adi/aajax/home;pos=0;sz=120x600;dcopt=;ptile=6;ord=59363123?;kw=homePage) there is no error.

These Permission denied messages are coming up for more method calls. Today's is: Permission denied to get property Element.childNodes http://www.loc8r.com/loc8r_Base.js Line 229 from http://www.loc8r.com/route.aspx?id=119 It seems to cause user's code to break but only when Firebug is running. That is, the exception only comes when Firebug is running and the exception breaks their code.

That doesn't seem to be this bug, since it DOES provide line/file information, doesn't it?

Yes, but this is not a syntax error so the developer can't diagnose the problem from file/line alone. Suppose I claim that all of these messages are actually bugs, not user/extension problems but platform errors. That is, I'll claim that the platform is throwing the exception when it should not. How would you refute this claim? I don't think there is a way, because nothing in the source or the exception can tell you that the call was not permitted. Similarly developers can tell either.

I wouldn't refute that claim at all, and think that we should have a bug on the fact that the exception is thrown at all in the unconnected-document case. Is there a small test case for producing the "Permission denied to call method {DOMThing}.{publicMethod}" error? I thought I saw one floating around somewhere, but can't find it now. I don't agree with the implication that only syntax errors benefit from file/line info, but we should provide more information here, like the principals involved or something similar. That's what this bug is about; if someone can find a bug about the fact that we're probably throwing this exception when we shouldn't, that would be good to mention here -- and then to continue that part of the discussion in said bug!

There is a test case on bug 440275.

We are starting to plan for Firebug 1.3. This bug is the second biggest problem we have. Any plan or ETA for a plan? Thanks!

Do you mean that the error message's lack of detail is the problem, or that getting the error at all is the problem? The bug with the test case (bug 440275) has a patch on it that's been committed to the trunk, so please do indicate there if you still get the error message at all with a recent-enough nightly. If it does fix things, then we should look at getting that patch into 3.0.2. If it doesn't, we'll need another test case, since it seems to fix the one that's attached. What information do you think should be in the error message, if it hasn't gone away? Would having the origins there help? (I don't think so, but I'm not the one debugging these cases.) I don't think there's anything the developer can do to avoid it, since it's a platform bug, but I don't really feel like putting lengthy apologia into the error message is the right path.

(In reply to comment #17) > What information do you think should be in the error message, if it hasn't gone > away? Would having the origins there help? (I don't think so, but I'm not the > one debugging these cases.) I don't think there's anything the developer can > do to avoid it, since it's a platform bug, but I don't really feel like putting > lengthy apologia into the error message is the right path. I assume that "permission denied" follows a permission test. The developer needs to know why they flunked the test. The information needed might include: 1) the code source that is attempting the call (some times called origin or principle? 2) the code source that is protected, 3) the capability that would allow the test to pass. Let's imagine then: Script from <site> does not hold <privilege>, denied access to <method.line> from <site>

For me as a developer, it would be good to know the global scope (the top-level/ browser window web adress) of an error. An extension (in attached mode, like Firebug) could filter the occourence of error messages to their context. Most of the discussed stuff is about subframes and violations of the Same Origin Policy.

(In reply to comment #19) > For me as a developer, it would be good to know the global scope (the > top-level/ browser window web adress) of an error. An extension (in attached I assumed that the filename and line number of the error message would be that information?

(In reply to comment #20) > I assumed that the filename and line number of the error message would be that > information? The first post describes errors created by iframes from doubleclick.com in the global scope. The errors are created by actionscript functions. Your error message would be: flashfile from doubleclick.com does not have the right to read the location of his parent frame from ajaxian.com because its not from the same domain. In a more nested environment we need the top level domain (and Firebug could discard the error if disabled).

(In reply to comment #21) > (In reply to comment #20) > > I assumed that the filename and line number of the error message would be that > > information? > > The first post describes errors created by iframes from doubleclick.com in the > global scope. > The errors are created by actionscript functions. > Your error message would be: flashfile from doubleclick.com does not have the > right to read the location of his parent frame from ajaxian.com because its not > from the same domain. > > In a more nested environment we need the top level domain (and Firebug could > discard the error if disabled). > But what would be the error message's filename. That is what Firebug would use to direct the error to the right place.

Just a suggestion:) [ajaxian.com/xy]html/body/iframe/[doubleclick.com/xy]/html/body/embed Don't know internals...

As a side-effect, Firebug's JavaScript console seems to cease printing any debug-level messages to the log after this error has occurred. Clarification in the error message description is helpful, but Firebug should not get derailed when this error occurs (which, for most developers, will be in 3rd party code).

(In reply to comment #24) > As a side-effect, Firebug's JavaScript console seems to cease printing any > debug-level messages to the log after this error has occurred. Clarification > in the error message description is helpful, but Firebug should not get > derailed when this error occurs (which, for most developers, will be in 3rd > party code). There are lots of different versions of this message, some trigger by user code some by Firebug (I guess, I can't actually tell). But in any case if you have a test case where Firebug stops working after one of these messages, please post it to our bug list so we can try to fix it: http://code.google.com/p/fbug/issues/list

The following Firebug issues are blocked by this bug: 614, 692, 817, 857, 932, 937, 986, 1005

Just to confirm, all of those are still present with builds that have the fix for 440275 (per comment 17): > The bug with the test case (bug > 440275) has a patch on it that's been committed to the trunk, so please do > indicate there if you still get the error message at all with a recent-enough > nightly. If it does fix things, then we should look at getting that patch into > 3.0.2. If it doesn't, we'll need another test case, since it seems to fix the > one that's attached. It looks like the test case in this bug is still broken, but the one linked in comment 440275 is fixed, so we need bugs on the different failures in addition to the "add some detail to the error message" one I'm commenting in now. We can dup different ones later if they turn out to be the same, but I'd rather err on having some DUPs to close than assume that we're just chasing one fix and find out later in the cycle that we have more of these to deal with than we'd thought. Rob: can you help with that?

(In reply to comment #27) > Rob: can you help with that? Just to clarify, you'd like separate bugs created for the issues mentioned in comment 26? Or just another more generic bug created for failures of {DOMObject}.{method}? I was able to repro the above test-case (the google one, anyway) pretty easily using current 3.0.1 and fb 1.2.07b.

(In reply to comment #26) > The following Firebug issues are blocked by this bug: 614, 692, 817, 857, 932, > 937, 986, 1005 I think I'm seeing about 3 classes of issues in these bugs, possibly all related, possibly different. 817 and 986 appear to be related to accessing DOM nodes in XML documents. 1005 is possibly related as it pertains to Xpath navigation, though may be different. The others are variations on a theme, either Element.getAttribute, Location.toString or History.item, for example. Standard DOM accessors. In all cases I tried, the examples seem to fail out as described in the testcase, reporting a Permission denied... error message, but only with Firebug installed. In one case, issue 817, I was able to get through the error condition by setting a break-point and stepping over it. I'll need to do some more investigation into the platform code that these methods are calling through, especially with respect to permissions to get a better understanding of the problem. I get the feeling it could be an interaction issue with Firebug and the platform code, but that is a very rough guess at the moment. More digging required!

changing platform as we're seeing these errors on all 3 of them.

> 817 and 986 appear to be related to accessing DOM nodes in XML documents. So bug 440275. I'd suggest installing Firebug on trunk (overriding the compat check) to filter out the noise from that bug... Patch coming up to improve the error reporting here.

With this patch, the toString error message starts to look more like this: Error: Permission denied for <http://ad.doubleclick.net> to call method Location.toString on <http://www.w3schools.com>. Wording improvements very much welcome. The first origin string there is the permissions the code is running with, the second one is the origin of the object it's touching. I suppose I could make it "on an object with origin <...>", but that seems very verbose...

I just realized that the origins reported with this patch don't take document.domain into account. Would origins that do take it into account be preferable?

On documents that show this error for me, it does not appear when I apply a breakpoint just before the error, then press Go to continue the code (without actually debugging). On another note, the error message should state why the permission check failed. The domains didn't match? State that and show the domains. Or is it just that you aren't allowed to mess with that property? Tell me that. Just a generic 'Permission denied' message is not very helpful, and dumping a lot of extra information that was used in the decision-making process might enable debugging, but is not very friendly on the developer (who must find the firefox source code and then follow the decisions made). If you can't make up enough messages to concisely communicate what is wrong, show a numeric code that can be looked up in the code or documentation.

> On another note, the error message should state why the permission check > failed. Yes. That's what this bug is about. And if you happened to have read it, or read the patch, you would have realized that.... Patch checked in, with a switch to origins taking document.domain into account, per conversation with John earlier today.

I put wanted on to see if we can get an ETA...

For what it's worth, I'm seeing this bug happen when *any* flash file, even ones that have NO actionscript calls (ExternalInterface, etc) in them at all, is loaded into an iframe on a page where the page domain and the iframe domain are different. This means that the iframe problem is caused when there is in fact a cross-domain situation in place. However, it's not totally clear if there's really actually attempting to be a cross-domain call that *should* be prevented and error'd out. Because it's nothing that the flash SWF itself is trying to call to do "Location.toString", and it's nothing about the javascript on the page doing it, the only choice is that there's something about the flash plugin itself (9.0.124 is what I'm testing with) that's trying to make that call up to the parent/top window to do Location.toString(). That quite possibly could be considered a flash plugin bug, but I can't speak to definitively if it's the plugin making that call without permission, or if it's FF misinterpreting what the plugin is doing and throwing that error spuriously. I think this behavior (at least related to the flash embedding) was introduced with 9.0.124 (but maybe as early as 9.0.115). Notably, this error is reported in the "Error Console" of FF regardless of if Firebug is installed or not. Additionally, it shows up the same in both FF2.0.0.16 and FF3.0.1 on windows, so it's been around awhile at least.

Do Firefox 3.1 nightlies from August 1 or later have this bug fixed? JJB: confirming that it solves the problem you care about will help us prioritize it for 1.9.0.x backport. Could you report back into this bug with your findings?

(In reply to comment #37) > Because it's nothing that the flash SWF itself is trying to call to do > "Location.toString", and it's nothing about the javascript on the page doing > it, the only choice is that there's something about the flash plugin itself > (9.0.124 is what I'm testing with) that's trying to make that call up to the > parent/top window to do Location.toString(). > > That quite possibly could be considered a flash plugin bug, but I can't speak > to definitively if it's the plugin making that call without permission, or if > it's FF misinterpreting what the plugin is doing and throwing that error > spuriously. Yes, indeed, plugins do that (not just flash) when they're initialized to know what origin their top frame comes from. The exact reasoning for it would need to be explained by the plugin vendors, but the call comes from the plugin and there's not much firefox can do about that (short of exposing other ways for plugins to reach the same information, which has been discussed already). > I think this behavior (at least related to the flash embedding) was introduced > with 9.0.124 (but maybe as early as 9.0.115). AFAIK flash and other plugins have been doing this for a looong time, it's nothing especially new.

(In reply to comment #38) > Do Firefox 3.1 nightlies from August 1 or later have this bug fixed? > > JJB: confirming that it solves the problem you care about will help us > prioritize it for 1.9.0.x backport. Could you report back into this bug with > your findings? > Using 3.1a2pre and the site in the Description, I get Permission denied for <http://ad.doubleclick.net> to call method Location.toString on <http://ajaxian.com>. Line 0 The error object is [message]=[JavaScript Error: "Permission denied for <http://ad.doubleclick.net> to call method Location.toString on <http://ajaxian.com>."]; [errorMessage]=Permission denied for <http://ad.doubleclick.net> to call method Location.toString on <http://ajaxian.com>.; [sourceName]=; [sourceLine]=; [lineNumber]=0; [columnNumber]=0; [category]=content javascript; No file, line number, or call stack. A *vast* improvement, thanks. Still consider that the developer probably did not call toString(), but used location in a string op. Firebug can, at best dump this message indiscriminately into all or no windows, and cannot link to the source line.

(In reply to comment #21) > (In reply to comment #20) > > I assumed that the filename and line number of the error message would be that > > information? > > The first post describes errors created by iframes from doubleclick.com in the > global scope. > The errors are created by actionscript functions. > Your error message would be: flashfile from doubleclick.com does not have the > right to read the location of his parent frame from ajaxian.com because its not > from the same domain. How do you know this is from actionscript/flashfile? Can we use the method you used to tell Firebug users this information?

There is no line number or call stack or filename available, I suspect, because the Flash plugin doesn't provide such to us (I don't know if it even can with the NPAPI). I don't know of a reasonable way to tell what plugin is calling us, even, let alone where in the plugin.

I have applied 3.1a2pre to the following issues from http://code.google.com/p/fbug/issues/list Issue 614: Permission denied for <http://code.google.com> to call method History.item@XPCSafeJSObjectWrapper.cpp:445.0 Issue 692: see comment 40. Issue 817: fixed (http://www.w3schools.com/DOM/tryit.asp?filename=try_dom_attributes) Issue 937 no longer gives permission error, instead it goes in to a loop reloading itself. Issue 986: Passed user's test (fixed). I believe the fixes are from 440275. Backporting that fix would be a high priority for Firebug. 614 is the problem I reported in 426131. There I claimed I understood why the message comes out, and maybe I do, but I still don't know how fix it.

Maybe it is possible that errorobjects get a frame reference (in this case two)? something like: [sourceFrame]=win; [targetFrame]=win; An extension could filter with a simple function like: function getRootWindow(win) { for (; win; win = win.parent) { if (!win.parent || win == win.parent || !(win.parent instanceof Window) ) if(win.console) return win; } return null; } Or would that leaking or getting other unseen problems? (In reply to comment #41) > How do you know this is from actionscript/flashfile? Can we use the method you > used to tell Firebug users this information? I didn't know - i assumed :) now i know it better.

(In reply to comment #42) > There is no line number or call stack or filename available, I suspect, because > the Flash plugin doesn't provide such to us (I don't know if it even can with > the NPAPI). I don't know of a reasonable way to tell what plugin is calling > us, even, let alone where in the plugin. Nevertheless you believe that this error message comes from a flash plugin. Why? You must be reasoning on some basis, can't we use that same logic to help those of us who don't know that pages can get errors from plugins? Isn't the plugin launched by Firefox because of an <object> or <embed> tag? can't we point to that tag or at least its file?

I believe that we're reasoning on the basis of observing the flash plugin with tools that are not available to the JS engine to report it, like the source files and in some cases debuggers. That's what I mean by "I don't know of a reasonable way to tell what plugin is calling us". If I knew of a way to point to the tag, I would have listed it; I am not lying to you about my ignorance. If you know of a way to point to the tag, I am eager to learn of it, genuinely. It may be that the filename of the iframe is available, as part of our hunt for the principal, but that might not be the filename responsible for the flash plugin being loaded from that domain if the frame is dynamically manipulated (a very common case, especially for advertisements). As per jst's comment, there is likely to not be anything that the developer can do to repair this situation, since it's inherent to the plugin, so I'm not sure what more detail will help, to be honest. (While I'm being honest, I also don't understand why you're reporting in this bug on the effectiveness of bug 440275's fix, rather than in that bug where it's more likely to be seen by people approving backport patches and landings.)

@Mike- While a developer can't do anything about the fact that the plugin is doing this, if it's more clear that it's actually coming from the plugin and not the developer's code, the developer can be saved from wasting lots of time trying to track down a ghost in their own code. This is exactly what happened to me. I spent 3 days trying to figure out why my flash/js code was doing this, before I finally figured out that my code had nothing to do with it. The crux of the matter that caused me the problem is that I was in fact calling from my actionscript a line of JS through ExternalInterface that called "window.location.href.toString", so this error seemed way too suspiciously like my valid code to not be related. The error says "Location.toString" which kept confusing me, because my call was "location.href.toString", but I assumed it was some transformation/translation of code that was happening inside of FF. I am embarassed to admit it took me 3 days before I realized I should just comment out the line from my flash. When I did, and the error still occured, *that's* when I knew it must be something different. But since the error didn't show me the exact line of javascript being executed, I was only left with assumptions. In the end, I figured out they weren't related, especially once I found this thread. I believe that having a reference to the plugin specifically would have at least let me know that it wasn't my javascript, and then I could have known it was flash-related for sure. Also, if the actual line of javascript being executed was reported/highlighted, and I could have seen if it was coming from flash's externalinterface bridge calls, then I would have known definitively if it was or was not my code that was the problem. If it could only point to the object tag, instead of a line of javascript, then it would be clear it was the plugin, and not developer code.

How would we highlight the line of source if it had been your script that was causing it? We don't see the source as source in your AS file, because that file is on your desktop and not sent to the browser, and Flash doesn't communicate to us the filename/linenumber to propagate. And when Flash does it, there is no "line of source" afaict, just method calls on objects from binary code. As far as I know, we cannot distinguish between "Flash did this because of something inherent to Flash" and "Flash did this because your script told it to": in both cases, we just see an access to a property coming out of Flash, and are given no way to distinguish them. If you want a way to distinguish them, you will need to ask Adobe to provide something to us. Maybe we should just not report security errors until they become uncaught exceptions? That would give Flash an easy way to suppress the messages from their exploration pokes, which I'm not sure they have right now (ref jst's comment 39).

If I make a call like this in my actionscript: ExternalInterface.call("alert('help'"); Note, the javascript is malformed, because there is no closing ) on the alert call. If I run that flash inside FF3.0.1, I get an error in the error console that looks like: missing ) after argument list http://www.myurl.com/blah try { __flash_toXML(alert('help'()); } catch (e) { "<undefined/>"; } This to me says that the flash plugin in fact uses a javascript function that they define ("__flash_toXML") which takes care of executing the javascript calls you make from inside actionscript. Therefore, it *is* a line of javascript that error console could refer to (*see below). It does have a try/catch around it, so it appears that anything other than malformed javascript just gets silently discarded. Only malformed javascript is able to force even the try/catch to fail, and thus report into the Error Console. Anyway, my hope or request was that errors that are reported would point to that line of javascript if they were developer-caused. It now appears that errors aren't reported at all (unless they truly are malformed, in which case at least the offending line of code is quoted, and makes it obvious what it's related to). But, my original point I think still stands, that in the case of plugin-caused errors (as opposed to developer caused errors), pointing to the object tag which caused the error would help distinguish between errors the plugin causes, and these types of malformed JS errors (which already correctly show the offending line of code). Granted, had I realized before this quest that the distinguishing between the cryptic "Location.toString" error and the one I posted above is already happening, I could have accomplished the same thing. My ignorance is clearly at fault (at least for the wasted 3 days!) I'm just suggesting that pointing to a specific object that caused it would be more helpful than just reporting some cryptic error not tied to anything I as a developer can see or have any control over. Moreover, what if there are multiple SWF's on a page, and this plugin behavior (calling Location.toString) was tied to some conditional logic for each SWF. For instance, maybe the plugin only makes that call if you import certain types of classes into your SWF, but not any direct actionscript code that the developer writes, like making ExternalInterface calls to javascript. In this case, if the error is reported and not associated with the object specifically, but just the plugin, then it's not clear to the developer which one of their SWF's is triggering the offending plugin behavior.

(In reply to comment #38) > JJB: confirming that it solves the problem you care about will help us > prioritize it for 1.9.0.x backport. I don't think we can backport it, actually, since it changes localization stuff.

Hi, I am a developer at Facebook. This bug is causing major problem with some new feature in Facebook Platform that utilize Flash for caching and cross domain XHR requests. I have to disable use of flash for Flash because of it. Even that does not solve the problem completely because if a Facebook app uses Flash themselves in conjunction, it will still fail for them. The most frustrating thing is that I can't find any way to get around it (other than not using flash). Reading all the post on this thread, I am still confused on whether there is a solution for this bug already. What can user of FF2 and FF3 do to avoid it? What can app developers to avoid it?

This bug was about the error message not providing enough information. We've added the information we can easily get at without seriously rearchitecting things. That's why this bug is marked "RESOLVED FIXED". I'm not sure how you managed to read all the posts without catching that part, to be honest. There are followup bugs on rearchitecting things, as well as other bugs about whether the error message should even be there: in certain cases it appears when it shouldn't. Sounds to me like you might be interested in one of the latter. But note that it may well be that Flash _is_ in fact doing something it shouldn't be, and our security policy is blocking it, and we're just reporting that. You can test a mozilla-central nightly or the upcoming Firefox 3.1 alpha 2 to see whether the most likely culprit for the error message appearing erroneously is what's hitting you.

Boris, Thanks for the clarification. I did read about your several posts that indicated that this bug is just about better reports, but several people seem to have followed up your posts to indicate that this is more than an better error report, but about the fact every flash object (no matter how simply) would break on Firefox. My impression is that these flash error only started to happen with recent Firefox updates. Is that correct? If so, I wish there could be better communication between Mozilla and Adobe so it can avoid breaking perhaps the more important Mozilla plug-in in the world.

> but several people seem to have followed up your posts to indicate that this is > more than an better error report Then they should really be filing separate bugs. One bug per problem. This bug is clearly just about the error report: just look at the summary. > Is that correct? I don't think so, no.

Wei: please file a bug with a test case; it's not clear at all what the failure mode is for Flash applications when this error is presented, or indeed even if there is one. Not all Flash objects break on Firefox, perhaps obviously, and per comment 39 we don't believe that this is anything new. (Perhaps also obviously: your test case should indicate how the observed behaviour is different from the expected behaviour, beyond an error message appearing in the console.) Thank you!

For what it's worth, I have not in any of my tests experienced any flash failures, only "unexpected" errors in the error console in FF2 and 3. And those errors with flash only seem to occur when the flash was placed inside an iframe and the iframe and main page are on different domains. So, all that being said, it's a fairly limited case, but is something for consideration given that's how a lot of flash ads work.

Kyle, in that situation Flash is just doing something it shouldn't and we block it. Please report that bug to Adobe if you haven't yet.

(In reply to comment #42) > There is no line number or call stack or filename available, I suspect, because > the Flash plugin doesn't provide such to us (I don't know if it even can with > the NPAPI). I don't know of a reasonable way to tell what plugin is calling > us, even, let alone where in the plugin. I would still like to confirm or refute Shaver's suspicion. If "no line number" means "error came from plugin" this is a valuable bit of information that will save lots of developers lots of time, even if we can't point to the line in the plugin or even say which plugin.

@Boris- I created this issue just now with Adobe: http://bugs.adobe.com/jira/browse/FP-561

Thanks. I will try to create repro sample and open a new bug.

For posterity sake: Adobe has now confirmed that this in fact a bug, them making that spurious call. They claim it's only cosmetic, and so it appears it may not get any priority from them to fix, but at least they admit it's a confirmable bug.

I just want to contribute by posting my observation re: this error. I am using Firefox 3.0.3 on Win XP with Firebug 1.2.1. I am seeing this same error at the following site, soon after enabling Firebug, without any additional action on my part: http://www.evotech.net/blog/2007/06/introduction-to-firebug/ Permission denied to get property Location.toString http://content.yieldmanager.edgesuite.net/flash_activate.js Line 21 Hope this proves useful. I will be happy to supply any additional information. As a software engineer, I am stunned by the functionality, utility, and design of Firebug. Simply amazing. Shows what open source is capable of, against closed systems such as Internet Explorer. Thanks to all who are involved. Todd

We can't take localization changes for this on the 1.9.0 branch. For debugging site problems developers can use a fixed 3.1 version, right? They shouldn't need the fix to be backported to a 3.0.x necessarily.

At least for Firebug this error message is filtered rather than showing in the console anyway.

Gentlemen... my apologies if I am writing to the wrong forum, but yours' was the only one I could find that seems to have a handle on this bug/exception/error Permission denied to call method Location.toString I am not a developer, programer, or really very technically savvy when it comes to these things, but I would like to think I do a fairly okay job at figuring out my own troubles except in this case. While I do understand that this is not a support site, I have no idea who to ask to assist me in resolving my issue. From what I do understand of what I read, your group appears to be aware somehow of the exact issue I have been having, although it seems that the topic has to do with the supply of information about the bug. I would very much appreciate it if any of you could direct me a place where a layman such as myself might be able able to resolve this bug for my own personal browsing purposes. If it is any help, I cannot seem to get one specific site to function after installing adblock through firefox on my laptop which runs Windows XP. The site is http://mlb.mlb.com/mlb/gameday/index.jsp?gid=2009_05_24_anamlb_lanmlb_1&mode=gameday (or any particular game on gameday icon function at left of the hompage coming from mlb.com as I happen to be a baseball writer. I thought adblock would increase my security, what it did was render the information I rely on for livlihood inaccessible. I tried to block (adblock) certain parts of the page such as ad.doubleclick.net and now I cannot access the function at all (including on Internet Explorer too!!) even though I have uninstalled the plug-in adblock, followed all the Flash directions meticulously etc. But the nature of this bug is beyond my comprehension at the moment, and I cannot seem to find a resolution for it anywhere, as of course this forum discussed the lack of information associated with it, of which I have virtually none. Any help or instruction on to find a fix or resolution to my issue would be very much appreciated. Thank you, Benj

(In reply to comment #66) ... > Any help or instruction on to find a fix or resolution to my issue would be > very much appreciated. Benj, based on the information you gave, the problem you have is not caused by any error related to the message being discussed here. Since you have a problem in Firefox and Internet Explorer, the likely source of your problem is not the browser. The likely causes would be your firewall or the site for example. I suggest you try Firefox SUMO. You can try to follow a procedure with Firefox called "create a new Firefox profile". It won't delete your old settings but it wills start a new pile of them, fresh like the first time. Benj's experience highlights why this entire set of problems around error message is so important. As an end user or developer these cryptic message waste our time.

Thank you Robert and Boris for your replies... it was my hope that my problem with this exact error code in my frefox browser might have elicited a response, but I certainly did not expect it. Robert I think your suggestion to try this SUMO sounded like a good idea, especially to avoid the loss of my settings, however my own urgency to get this thing fixed after spending more time than I would have liked on it without making any progress led me to these steps. After unsuccessfully trying System Restore several times, I decided to give my system a hearty flush, full-well knowing the expense it would cost to my bookmarks, settings, and other add-ons. I used the advanced feature of VS Revo Uninstaller to remove my Java, my Flash Player, and Firefox... running it twice on each before closing it eash time to make sure it got rid of any lingering registry stuff that I generally have no grasp as to the function of what these entries do in general. BTW, Revo is a quite a powerful, free program, that as a general consumer, I recommend if you are not familiar. I then ran Dial-a-Fix, which is another free application my cousin who is an IT guy turned me on to, but had never tried. It basically attempts to return a system to its standard setting associations, but on a very advanced level for someone like myself. I restarted, re-installed flash player, and voila, Internet Explorer finally was able to access the site in question. I then re-installed my Firefox from scratch and imported most of my bookmarks back. The only issue I have now is that Java, while appearing to work properly, does not show up as installed, and when I tried to re-install it, it said it was already installed, however, I am fairly positive that it is not the latest version, but I guess as long as things seem to be working okay again, I really can't complain too much. What I do know about this error from a somewhat exhaustive search on the internet is that, any help that is out there regarding this issue appears to be way above my head, but in case any of you find it of interest I am including the one link that seemed to address my issue, but I really could not make heads nor tails of it's content for it to be of any help: http://willperone.net/Code/as3error.php Thank you for your efforts, if you're inclined to steer me in the right direction with my new Java problem, do feel free. I will say that I wish I had tried the SUMO first, although after Googling it, I am not sure if I would have been able to figure out how to implement that either.. oh well, live and learn. Best Regards, Benj

Sorry John, did not mean to call you Robert... was noticing Boris was at MIT, where my Uncle Robert attended for Statistics. Very tired.

This problem persist event today. When I tried to embed a facebook video in iframe, this error occured in Firefox. <iframe width="720" height="1280" frameborder="0" src="https://www.facebook.com/video/embed?video_id=627802933963417">

alexforever86@gmail.com, the security subsystem got rewritten, so it's possible this problem was reintroduced. Please file a new bug if it's still happening.

Reopened bug is here: https://bugzilla.mozilla.org/show_bug.cgi?id=385676 and here: https://bugzilla.mozilla.org/show_bug.cgi?id=1015700