W3C home > Mailing lists > Public > public-html@w3.org > January 2011

Re: script execution corner case: timing of running a script created from a javascript: URL inside an IFRAME

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 19 Jan 2011 13:28:42 -0500
Message-ID: <4D372D5A.5070609@mit.edu>
To: Ojan Vafai <ojan@chromium.org>
CC: "Hallvord R. M. Steen" <hallvord@opera.com>, public-html@w3.org
On 1/19/11 1:04 PM, Ojan Vafai wrote:
> I believe WebKit is sync for javascript, data and empty URLs. Being sync
> for these cases is so much more convenient for web developers that have
> to deal with iframes. Especially as we are starting to add APIs for
> using iframes in lighter-weight contexts (e.g. seamless), this will
> become more important.
>
> Are there any disadvantages to making these cases sync?

Yes.

1)  It makes the mental model inconsistent for developers (some loads 
are sync, some are async).  For example, trying to detect a load 
completing by using an onload handler involves knowing what sort of url 
you're loading, because otherwise the load may be done before you've set 
up your onload handler.  Or requires very carefully ordering your 
operations as you insert the new element.  This applies to all three of 
the cases above.  Unless the load event is still async, of course... in 
which case in what sense are things sync here?

2) It's not what browsers used to do, certainly (see 
https://bugzilla.mozilla.org/show_bug.cgi?id=351633#c0).  Right this 
second it's not what Safari 5 does if you load 
http://web.mit.edu/bzbarsky/www/testcases/javascript-url/sync-vs-async.html 
and click "Test iframe"

3) For the javascript: case, it significantly simplifies implementation, 
especially if you want to support javascript: in a variety of contexts 
(as Gecko does) because you don't have to worry about random script 
executing in the middle of other operations.

-Boris
Received on Wednesday, 19 January 2011 18:29:19 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:21 UTC