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

[Jonas Sicking]

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.


I'm personally leaning towards 3 or 1. If we go with 3 pages can
always call the API and remove the script in order to get buggy
"working" behavior in contemporary browsers.

/ Jonas