[whatwg] Javascript: URLs as element attributes

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 <embed>, only Firefox does this (tested using window.alert). I didn't 
test further with <embed> since there doesn't seem to be a use case for 
this anyway.

I didn't test <applet>.


> 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.


> > > For what it's worth, as I see it there are three possible behaviors for
> > > a javascript: URI (whether in an attribute value or elsewhere):
> > > 
> > > 1)  Don't run the script.
> > > 2)  Run the script, but in a sandbox.
> > > 3)  Run the script against some Window object (which one?)
> > > 
> > > Defining which of these happens in which case would be good.  
> > > Again, Gecko's behavior is #2 by default (in all sorts of 
> > > situations; basically anywhere you can dereference a URI), with 
> > > exceptions made to do #3 in some cases.
> > 
> > That's what the spec says currently.
> 
> That doesn't agree with your comments about <script src> above...

Indeed, I misspoke. The spec actually defaults to not running the script, 
but in most circumstances of interest does #2, and in a number of other 
cases does #3 or does #1 explicitly even if it would otherwise do #2 or 
#3. It's complicated. :-)


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.


> 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.

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.


On Tue, 30 Nov 2010, Boris Zbarsky wrote:
> 
> 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:?

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

Received on Wednesday, 9 February 2011 19:12:09 UTC