(this is not a JS engine issue, nor a prefs issue so I'm not posting
this reply to those newsgroups)
Brett Granger wrote:
>
> Sorry for the wide post, not sure which of these newsgroups this really
> falls under...
>
> We have a Flash application that runs with the Flash 5.0r47 plugin and
> mozilla 0.9.4 on Linux. In this application, we have a button with the
> following actionscript attached to it:
>
> on(release) {
> getURL ("javascript:getApp();")
> }
>
> Normally, this URL works just fine and all goes well. However, if the
> "browser.target_new_blocked" pref is set to true, this button now ceases
> to work and the following error appears on stdout:
>
> Error loading URL javascript:getApp(); : 805303f5
>
The messages about not being able to load javascript: URL's are bogus,
ignore those, they mean nothing (and should be removed).
> The error is NS_ERROR_DOM_RETVAL_UNDEFINED, and the only place in the
> source code that it makes sense for this error to be coming from is line
> 234 of nsJSProtocolHandler.cpp. Supposedly this generates the following
The error NS_ERROR_DOM_RETVAL_UNDEFINED is used by the javascript:
protocol handler to communicate to the network library that the script
in the URL didn't return a value (or the returned value was
|undefined|), this tells the networking code, or rather the docshell
code, to *not* load the result of executing the javascript: URL into the
window where the URL was loaded.
> string to the js console: "Attempt to load a javascript: URL from one
> host in a window displaying content from another host was blocked by the
> security manager." I don't have access to the js console at this point
> to see whether this string is really being generated or not (is the
> console output logged to some file where I can get it?).
>
The console output is not logged anywhere, but you should always be able
to open the javascript console and see the errors (Tasks->Tools->JavaScript
Console).
> All "windows" are using http://localhost as far as I know, so I don't
> understand the error. Also, why should target_new_blocked affect this at
> all? The comments in this code imply "the principals aren't equal".
> Could the app running in the Flash plug-in have a different principal
> than the window which encapsulates it? I know nothing about principals
> or how they work. However, when browser.target_new_blocked is returned
> to false, all starts working again.
>
> Can anybody give me any pointers as to why this pref is causing this
> problem?
>
I fail to see how this would be related to the target_new_blocked, Mitchell,
ideas?
> TIA,
> --Brett Granger
>
>
--
jst
