[whatwg] Behavior when <script> is removed from DOM

On Wed, Dec 7, 2011 at 12:01 PM, Jonas Sicking <jonas at sicking.cc> wrote:

> On Wed, Dec 7, 2011 at 11:27 AM, Adam van den Hoven <adam at littlefyr.com>
> wrote:
> > On Sat, Dec 3, 2011 at 9:17 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> >>
> >> On Sat, Dec 3, 2011 at 7:38 PM, Yehuda Katz <wycats at gmail.com> wrote:
> >> >
> >> > Yehuda Katz
> >> > (ph) 718.877.1325
> >> >
> >> >
> >> > On Sat, Dec 3, 2011 at 6:37 PM, Jonas Sicking <jonas at sicking.cc>
> wrote:
> >> >>
> >> >> On Sat, Dec 3, 2011 at 6:24 PM, Yehuda Katz <wycats at gmail.com>
> wrote:
> >> >> >
> >> >> > Yehuda Katz
> >> >> > (ph) 718.877.1325
> >> >> >
> >> >> >
> >> >> > On Fri, Dec 2, 2011 at 11:30 AM, Tab Atkins Jr.
> >> >> > <jackalmage at gmail.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> On Fri, Dec 2, 2011 at 11:27 AM, Jonas Sicking <jonas at sicking.cc>
> >> >> >> wrote:
> >> >> >> > The main use case for wanting to support scripts getting appears
> >> >> >> > to
> >> >> >> > be
> >> >> >> > wanting to abort JSONP loads. Potentially to issue it with new
> >> >> >> > parameters. This is a decent use case, but given the racyness
> >> >> >> > described above in webkit, it doesn't seem like a reliable
> >> >> >> > technique
> >> >> >> > in existing browsers.
> >> >> >>
> >> >> >> If it's unreliable *and* no sites appear to break with the proper
> >> >> >> behavior, we shouldn't care about this use-case, since
> cross-domain
> >> >> >> XHR solves it properly.
> >> >> >
> >> >> >
> >> >> > Cross-domain XHR *can* solve this use case, but the fact is that
> CORS
> >> >> > is
> >> >> > harder to implement JSONP, and so we continue to have a large
> number
> >> >> > of
> >> >> > web
> >> >> > APIs that support JSONP but not CORS. Unfortunately, I do not
> forsee
> >> >> > this
> >> >> > changing in the near future.
> >> >>
> >> >> I think we can solve this in 3 ways:
> >> >>
> >> >> 1. Keep spec as it is. Pages can simply ignore the JSONP callback
> when
> >> >> it happens.
> >> >> Disadvantages:
> >> >> Additional bandwidth.
> >> >> More complexity for the web page.
> >> >>
> >> >> 2. Make removing scripts cancel any execution
> >> >> Disadvantages:
> >> >> Pages will have to deal with the fact that removing scripts can still
> >> >> cause the callback to happen if the load just finished. So the same
> >> >> amount of complexity for page authors that don't want buggy pages as
> >> >> alternative 1.
> >> >> Since many pages likely won't properly handle the callback happening
> >> >> anyway will likely cause pages to be buggy in contemporary browsers.
> >> >>
> >> >> 3. Add a new API to reliably cancel a script load
> >> >> Disadvantages:
> >> >> New API for pages to learn.
> >> >
> >> >
> >> > 4. Add a new API (or customize XHR) to explicitly support JSONP
> >> > requests,
> >> > and allow those requests to be cancelled.
> >>
> >> Yes, that's definitely an option.
> >>
> >> It will be sort of a weird API since the security model will be sort
> >> of strange. Traditionally we say that you can't load data cross site,
> >> but that you can execute scripts cross site. Here we want something
> >> sort of in between.
> >>
> >> It could have significant advantages if it makes it easier for sites
> >> to do cross-site loading of data without exposing themselves to XSS
> >> risks.
> >>
> >> / Jonas
> >
> >
> > If we went for a hybrid approach, namely that XHR has a cancellable way
> to
> > call and execute some arbitrary JavaScript and sandbox the execution so
> that
> > "this" is something explicitly provided to the XHR, would we not suddenly
> > have a rather secure way to load any javascript in general (and probably
> > make things like lab.js and yepnope easier to write)? Now I can load some
> > javascript (say from some ad server) without giving it access to the
> window
> > object and the global scope, if I don't want to. Wouldn't this address
> some
> > of the security issues that Doug Crockford has brought up in the past?
>
> Yeah. This would be very cool. Proposals more than welcome, though I
> would suggest not tying it to XHR but rather have a dedicated "load
> and execute this url in this sandbox" API.
>
> Designing a sandbox API is likely a fairly large task. I believe that
> ES.next might have something to that extent but I'm not fully sure.
>
>
Yeah, the "modules" proposal for ES "harmony" is fairly similar:
http://wiki.ecmascript.org/doku.php?id=harmony:modules

The relative bits for this thread are that a script can be loaded into a
new pristine global environment (i.e. it doesn't just get to party on
window, is shielded from any prior monkeying with Object.prototype, etc)
and decides what to export (by applying properties to its global object);
the script doing the import can decide what to pick up from from the global
object of the imported module.

This can't be implemented in JS today (e.g. as a shim) since that "evaluate
this script text in this new global sandbox" bit isn't present.


> A dedicated JSONP API is likely a lot simpler to design and could be
> specced and rolled out quicker. But of course has a smaller feature
> set.
>
> / Jonas
>
> / Jonas
>

Received on Wednesday, 7 December 2011 12:22:51 UTC