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

[Yehuda Katz]

The modules proposal, though, is coupled to other ES6 features, and, unless
I'm mistaken, is not a simple way to load and execute ES3 content.

It would be nice to do a DOM-based proposal for loading and executing
(optionally) sandboxed ES3 content, and not require a choice between the
current somewhat unpleasant situation and a full-on upgrade to ES6.

Yehuda Katz
(ph) 718.877.1325


On Wed, Dec 7, 2011 at 12:22 PM, Joshua Bell <jsbell at chromium.org> wrote:

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