736300 - Clicking x-cz-command URLs doesn't work anymore: WARNING: No principal to execute JS with: file …/nsJSProtocolHandler.cpp, line 190

Status: RESOLVED FIXED

(Other Applications :: ChatZilla, defect)

Description

[Karsten Düsterloh]

Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120313 Firefox/13.0a1 SeaMonkey/2.10a1, built with Chatzilla 0.9.88.1 included.

Certain features of Chatzilla generate clickable links in the content window, pointing to URLs like href="x-cz-command:$COMMAND".
These command links don't work anymore, only a warning gets dumped to the shell:

WARNING: No principal to execute JS with: file /…/mozilla/dom/src/jsurl/nsJSProtocolHandler.cpp, line 190

Steps to reproduce:
- Start Chatzilla
- Open moznet
- In the line "[INFO]Connecting to irc://moznet/ (irc://irc.mozilla.org/)… [Cancel]", the "[Cancel]" is a link to "x-cz-command:cancel".

Background:
Chatzilla dynamically creates a browser, adding an onclick attribute:
<http://mxr.mozilla.org/comm-central/source/mozilla/extensions/irc/xul/content/static.js#3641>. This onclick code doesn't get called anymore.

This is especially mean, because DCC interaction provides various commands this, all of which don't work anymore. 

Reading through IRC logs, I suspect a same/similar cause like for bug 728313 (bug  658220?), thus adding bz and Gavin and hoping for any insight. ;-)

Comment 1

[James Ross]

I'm guessing it is also the cause of bug 735611.

Comment 2

[James Ross]

This appears to be broken in the Firefox 11 release. :(

Comment 3

[Boris Zbarsky [:bzbarsky]]

Is Chatzilla basically using javascript: links in chrome-principal documents?

Comment 4

[James Ross]

We're setting location.href to a javascript: URL on a chrome: document loaded in a <browser> in a chrome: XUL window.

Luckily, I don't really care about what has "broken" in the platform this time; I've found a much simpler solution for the code.

Comment 5

[James Ross]

Attachment: Simplify inline button activation code to avoid javascript: protocol

Comment 6

[Boris Zbarsky [:bzbarsky]]

> We're setting location.href to a javascript: URL on a chrome: document

Is the browser a <browser type="content">?

Comment 7

[Karsten Düsterloh]

(In reply to Boris Zbarsky (:bz) from comment #6)
> > We're setting location.href to a javascript: URL on a chrome: document
> 
> Is the browser a <browser type="content">?

Yes.

Comment 8

[Boris Zbarsky [:bzbarsky]]

> Yes.

Then the behavior change is expected per bug 723808...

Comment 9

[Boris Zbarsky [:bzbarsky]]

Oh, and loading system-principal things in type="content" docshells is generally a bug.  One of these days we'll drop support for it altogether....

Comment 10

[James Ross]

(In reply to Boris Zbarsky (:bz) from comment #9)
> Oh, and loading system-principal things in type="content" docshells is
> generally a bug.  One of these days we'll drop support for it altogether....

Unfortunately, we have to do it because of OTHER bugs. See bug 370760 for the details.

Comment 11

[Boris Zbarsky [:bzbarsky]]

The three issues there are, in order:

1) fixed
2) will stop being an issue before the change in comment 9 is made (support for chrome-type
   tabs for system stuff will be added)
3) never got filed; if you want it fixed file with a clear description of the problem.

Comment 12

[James Ross]

That wasn't a comprehensive list.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Well, if you have other issues, file them.  The current thing with allowing chrome stuff in content-type docshells is somewhat insecure, so we would really like to remove it one of these days.

Comment 14

[James Ross]

http://hg.mozilla.org/chatzilla/rev/69466916bb21