W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2010

[whatwg] Javascript: URLs as element attributes

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 30 Nov 2010 14:30:31 -0500
Message-ID: <4CF550D7.5080606@mit.edu>
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?

Received on Tuesday, 30 November 2010 11:30:31 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:28 UTC