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

[Yehuda Katz]

Yehuda Katz
(ph) 718.877.1325


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

This would be amazing and make it easier to write JSONP code as well.


>
> Adam
>