[webkit-dev] Suggestion: runtime disable Fetch API until it's complete enough for real web-apps
youennf at gmail.com
Thu Mar 31 11:18:29 PDT 2016
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
Le jeu. 31 mars 2016 à 20:14, youenn fablet <youennf at gmail.com> a écrit :
> 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
> 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
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev