[whatwg] Javascript: URLs as element attributes

Boris Zbarsky bzbarsky at MIT.EDU
Tue Nov 30 11:30:31 PST 2010

On 11/30/10 4:35 AM, Philip Jägenstedt wrote:
> No, as far as I know, Opera hasn't ever sandboxed any inline javascript:
> URL execution.

So <img src="javascript:"> runs the JS in the page's context in Opera?

>> Also, note that <embed src="javascript:"> and <applet
>> something="javascript:"> (can't recall the attr name right now) also
>> execute the script in Firefox. Do they in Opera?
> Neither of these execute in Opera, both were explicitly blocked before I
> started looking into the issue. Note that I can't get <applet
> something="javascript:"> to execute in Firefox either, perhaps it needs
> a special value for "something"

Right; see the "can't recall" bit above.  code="javascript:" maybe?

> or the Java plugin must be installed?

This might be needed too, yes.

> It seems to me that after sandboxing, javascript: URLs will be quite
> useless. You can only use them where the content is text

That's not the case, actually.  At least in Gecko, the return value 
string is examined to see whether all the charcode values are < 255.  If 
they are, then the string is converted to a byte array by just dropping 
the high byte of every char.  So you can pretty easily generate image 
data this way.

If any of the bytes are > 255, then the string is encoded as UTF-8 instead.

> and the script has to be completely self-confined


> Using data: URLs will allow you to
> generate the data in the outer environment, and it's possible to
> generate binary data.

Right.  Now that data: support is universal, there may be a lot less 
need for javascript: returning data, except for compat reasons.

> So far, it seems that the fastest way to reach compat between browsers
> is to simply not run inline javascript: URLs.

Except for frames/iframes, right?


More information about the whatwg mailing list