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

[whatwg] Javascript: URLs as element attributes

From: Philip Jägenstedt <philipj@opera.com>
Date: Tue, 30 Nov 2010 10:35:18 +0100
Message-ID: <op.vmy8w4vgsr6mfa@kirk>
On Mon, 29 Nov 2010 16:36:32 +0100, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 11/25/10 9:10 AM, Philip J?genstedt wrote:
>> Based on this, unless there are corner-cases I've missed, it seems
>> unlikely that there's a large body of web content that depends on inline
>> javascript: URLs executing. My current plan is to try completely
>> blocking javascript: URLs in the contexts mentioned above. This seems to
>> be the simplest to implement and the fastest way to reach
>> interoperability. The alternative is to start executing javascript: URLs
>> in more contexts, which, even if sandboxed, doesn't seem particularly
>> useful.
>
> Does Opera sandbox <object data="javascript:">?  Note that Firefox does  
> not.

No, as far as I know, Opera hasn't ever sandboxed any inline javascript:  
URL execution. That's one reason why it's easier to just not run them at  
all.

> 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" or the Java plugin must be installed?

>> I'll keep you posted if there are any compatibility issues that come up
>> with this. Assuming (boldly) there is not, would there be support from
>> other browsers to move in this direction and change the spec to match?
>> (It seems that IE and WebKit are already basically already doing what
>> I'm advocating.)
>
> The reason Firefox runs javascript: in <object> is  
> <https://bugzilla.mozilla.org/show_bug.cgi?id=300263>.  I could probably  
> be convinced to either run it in a sandbox or not run altogether, though  
> I would strongly prefer the sandbox approach....

Thanks for that pointer. For those who don't want to dig, it was about  
generating a SVG document for <object data="">. The demo  
<https://bug300263.bugzilla.mozilla.org/attachment.cgi?id=188843> will  
break if you start sandboxing the execution as per spec, as it refers to  
eg_svg from the outer environment. It also doesn't currently work in  
Opera, it seems like we just execute <object data="javascript:">, but  
don't use the return value as the document. Since it also won't work in IE  
or WebKit, it seems unlikely that there's much content depending on this.

It seems to me that after sandboxing, javascript: URLs will be quite  
useless. You can only use them where the content is text, 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.

For reference here's the same demo done with a data: URL instead:  
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/721 Unlike the  
javascript: version, this actually works in Opera, Firefox and presumably  
all browsers that support SVG in <object> and data: URLs.

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

-- 
Philip J?genstedt
Core Developer
Opera Software
Received on Tuesday, 30 November 2010 01:35:18 UTC

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