[whatwg] Javascript: URLs as element attributes

On Wed, 9 Feb 2011, Boris Zbarsky wrote:
> On 2/9/11 10:12 PM, Ian Hickson 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:">

(Note that the spec has since changed on this; javascript: either runs in 
a browsing context that it is navigating, or it doesn't run at all.)


> > > > 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.
> 
> Try this:
> 
>   data:text/html,<body onload="alert(window[0].location)"><iframe src="javascript:''">

Woah, funky. (Gecko thinks the location is "javascript:''".)


> > > Note that there is some confusion here in terms of browsing contexts 
> > > and <object>, since<object> does expose a Document object sometimes 
> > > (but not others) and does participate in session history sometimes, 
> > > I believe... So I'm not quite sure what behavior the spec calls for 
> > > for<object>.
> > 
> > It's defined; see the section on the<onject> element.
> 
> I've read that section, in fact.  I couldn't make sense of what behavior 
> it actually called for.  Has it changed recently (last few months) to 
> become clearer such that rereading would be worthwhile?

Not as far as I'm aware. Could you elaborate on how it is confusing? I'm 
eager to make this understandable!


> > > 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.
> > 
> > Hm. This currently isn't specced; the spec just assumes the return 
> > value is text/html string data and doesn't say what encoding to use. 
> > Is there a good way to test this in the context of an<iframe>, where 
> > all the browsers do something with javascript:?
> 
> <body onload="alert(window[0].document.characterSet)"><iframe src="javascript:'\u0400'">

http://junkyard.damowmow.com/466

Gecko: UTF-8 if the 'javascript:' URL includes characters >255, ISO-8859-1 
if all the input characters are <255.

WebKit seems to pick my default encoding regardless.

Opera returns "".

IE8 returns "undefined".

Since Gecko seems to be alone in this weird behaviour, I haven't specced 
it. I couldn't find any other effect (e.g. the input seems to always be 
treated as Unicode, not converted to bytes and redecoded, regardless of 
what I make it look like, including UTF-16 and UTF-8).


On Thu, 10 Feb 2011, Adam Barth wrote:
> On Tue, Nov 30, 2010 at 11:37 AM, Darin Adler <darin at apple.com> wrote:
> > In WebKit, we have treated the javascript URL scheme as a special 
> > case, with explicit code in the loader, and not handled by general 
> > purpose resource protocol machinery. Maciej Stachowiak suggested this 
> > approach, back in 2002, and one of the reasons he gave me at the time 
> > is that thought WebKit would be more likely to get the security policy 
> > right if code paths opted in to JavaScript execution rather than 
> > opting out of javascript URL scheme handling.
>
> Apologies for not reading the whole thread before replying, but the 
> design Darin describes [above] has worked well in WebKit thus far.  I'd 
> be hesitant to make JavaScript URLs work in more contexts due to the 
> risk of introducing security vulnerabilities into the engine.

That's black-box equivalent to what the spec currently requires, I believe 
(though the spec implements it more like what Boris describes:).

On Thu, 10 Feb 2011, Boris Zbarsky wrote:
> 
> For what it's worth, Gecko treats javascript: URLs as a general 
> protocol, but with tracking of where the URL came from required for the 
> script to actually execute and explicit opt-in on the caller's part 
> required to execute outside a sandbox.
> 
> This too has worked well in terms of security, for what it's worth, 
> while offering a lot more flexibility in terms of how and where 
> javascript: URIs can work.
> 
> I don't think we should gate the spec here on Webkit's implementation 
> details if we think a certain behavior is correct but hard to support in 
> Webkit....


On Mon, 16 May 2011, Philip J?genstedt wrote:
> On Sat, 14 May 2011 00:34:36 +0200, Ian Hickson <ian at hixie.ch> wrote:
> > On Mon, 14 Feb 2011, Philip J?genstedt wrote:
> > > 
> > > 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.)
> > > 
> > > [...]
> > > 
> > > 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.
> > 
> > Since only Firefox now supports this, I've removed support for it from 
> > the spec. (It's just commented out for now; we can put it back if 
> > someone makes a compelling argument.)
> 
> Great! I can report that the changes to block inline javascript: URLs 
> went into Opera 11.10 and so far I'm not aware of any site compat issues 
> having being caused by it.

Excellent.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 6 June 2011 16:45:28 UTC