[webkit-dev] Suggestion: runtime disable Fetch API until it's complete enough for real web-apps

[youenn fablet]

Woups, the mail went out too fast.
Fetch API is not yet supporting some options like CORS at the moment.
I think we should expose fetch once it is using properly all existing
ThreadableLoader options.
   y


Le jeu. 31 mars 2016 à 20:14, youenn fablet <youennf at gmail.com> a écrit :

> Hi,
>
> I like the idea of a runtime flag.
> I would wait to enable fetch use until it passes sufficient numbers of
> web-platform-test tests.
> This can be tested in http://w3c-test.org/tools/runner/index.html (folder
> fetch/api).
> I think th
>
> Also, are you suggesting that it would be in addition to the compile flag
> or as a replacement?
>
>
>
> Le jeu. 31 mars 2016 à 20:06, Timothy Hatcher <timothy at apple.com> a
> écrit :
>
>> On Mar 31, 2016, at 10:02 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>>
>> The recently released Safari Technology Preview has gotten more people
>> living on builds close to trunk, which is cool. Some people pointing out
>> that the current state of Fetch API causes problems - it's not quite
>> complete enough for real web apps that want to use it, but its presence
>> breaks the detection that would substitute a polypill.
>>
>> I'd like to suggest that it should be disabled until it's complete enough
>> to work. I would propose a runtime flag instead of compile-time so it can
>> continue to be tested by our regression tests while it's getting finished
>> up.
>>
>>
>> It is is way better shape in trunk. It really just missed the Safari
>> Technology Preview build by a couple days. A fetch example I have now works
>> in a trunk Safari build for example.
>>
>> I think we can keep it enabled and have it be in the next Safari
>> Technology Preview release. We do need to be careful with things like this
>> in the future though.
>>
>> — Timothy Hatcher
>>
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20160331/2011a902/attachment.html>