[whatwg] Javascript: URLs as element attributes

[Philip Jägenstedt]

On Thu, 10 Feb 2011 04:12:09 +0100, Ian Hickson <ian at hixie.ch> wrote:

> On Mon, 15 Nov 2010, Boris Zbarsky wrote:
>> On 11/15/10 8:15 PM, Ian Hickson wrote:
>> > > Gecko's currently-intended behavior is to do what [the spec]
>> > > describes in all cases except:
>> > >
>> > >    <iframe src="javascript:">
>> > >    <object data="javascript:">
>> > >    <embed src="javascript:">
>> > >    <applet code="javascript:">
>> >
>> > What does it do for those cases if it doesn't match the spec?
>>
>> For <iframe> the behavior in Gecko currently is different in terms of
>> what the URI of the result document of javascript: is set to.
>
> How does it differ? As far as I can tell, it works the same as the spec
> says (the document.location is "about:blank" in the example above).
>
>
>> For the others, I believe we execute them in the script environment of  
>> the
>> owner document of the object/embed/applet, whereas the spec requires  
>> them to
>> execute in a sandbox, as far as I can tell.
>
> Ah, interesting. For <object>, this seems to be a unique feature of
> Firefox. Opera also executes the script in the context of the owner, but
> then ignores the results as far as I can tell. Other browsers don't seem
> to support javascript: in data="" at all.

For the record, I removed Opera's "support" (I assume it was an unintended  
side-effect) for <object data="javascript:..."> along with the rest at the  
time when I wrote my previous mail in this thread. This intentionally  
doesn't match what the spec says. (Disclaimer: this is only my opinion on  
something that isn't really my area of expertise, so others at Opera might  
decide that the spec is great and push in the opposite direction. It seems  
unlikely at this point, though.)

> On Thu, 25 Nov 2010, 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.
>
> There's a minor body of work on the Web that is based on using  
> javascript:
> URLs to generate bitmaps, and I don't really see any harm with this.

Even if there's no harm, it's unneeded complexity that so far doesn't seem  
to be needed for web compat, since it currently would only work in Firefox.

>> 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?
>
> What the spec currently specs seems to be a reasonable compromise between
> security, compatibility needs based on what browsers do today, use cases,
> and consistency across the platform (usability), in that order.

What compatibility needs? The only thing I'm aware of is using <img  
src="javascript:..."> to generate X BitMap images.[1][2] However, the  
examples would break if the execution was sandboxed as per the spec.

> Obviously if browsers implement something different, then I'll happily
> move the spec to match, but it would be sad to just close off these
> features without good reason.

Of what has been brought up so far, javascript: as an inline resource is  
not very useful at all, so IMO the only reason to keep it would be for  
legacy compat. I'll follow up on this again once the change to block  
inline javascript: URLs in Opera has been in the wild for a while,  
hopefully reporting that no compat issues have arisen.

[1]  
http://www.ridgway.co.za/archive/2005/11/13/dynamicjavascriptimagegenerationwithxbmimages.aspx
[2] http://david.blackledge.com/XBMDrawLibrary.html

-- 
Philip Jägenstedt
Core Developer
Opera Software