[Webkit-unassigned] [Bug 138169] WKWebView does not fully support custom NSURLProtocol

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Jun 1 13:20:01 PDT 2016


https://bugs.webkit.org/show_bug.cgi?id=138169

--- Comment #21 from Stefan Arentz <stefan at arentz.ca> ---
(In reply to comment #20)

I also want to clarify something with regards to 'please file more detailed bugs' and the following is actually a great example:

> Concerning WebP support, Chrome did the following things:
> 1.) Appended WebP to Accept request header, so server could respond with
> WebP images
> 2.) Decoded responses with WebP mime types and replaced them with images
> supported by UIWebView
> Neither request part, not response is possible with WKWebView.

Since WKWebView has been introduced in iOS 8, almost 2 years ago, its API has moved forward / opened up *very very little*.

This despite dozens of feature requests being filed. Mozilla has filed a good number. So has every other browser vendor and many individual developers. Lots is still missing. From basics (cookie policy configuration or even setting custom headers) to more complicated things like access to networking. Which is what this bug is about.

Almost none of these filed feature requests have been implemented or even given attention on this bugtracker. This is not a surprise. WebKit on iOS is a complicated component and I think we all fully understand how Apple is a) resource constrained and b) cautious of introducing APIs that it needs to support into the very long term future.

The problem however is that after 2 years WKWebView is still very limited. So limited that people are talking about moving back to UIWebView. Mozilla included.

So back to the WebP example from above. I don't think that filing narrow and detailed requests like that is going to make a difference. The past years have proven that.

This is why everyone is asking to open up WKWebView more and specifically the networking part of it. These are *generic* changes we are asking for. Open ended. It is not specific on purpose, so that we, developers, can just do what we need to do to build interesting and competitive features. Without having to ask Apple to spend engineering time on a long list of very specific features.

Networking is the thread that connects most of the things that we want to do. With access to networking we can implement *so many* things that are now missing in WKWebView.

And that is why WebP is actually a great example. A technically complicated feature for Apple to implement. (CoreImage changes, policitical, etc.) But Google can just do it if they could set headers and intercept loads.

Networking is that Generic API that would open up WKWebView and make it 10x more usable.

I'll keep filing specific bugs for thigns that we want. Pretty much everything mentioned in this thread already has bugs. But also please consider opening up the networking for the above reasons.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160601/dfbb8c6d/attachment-0001.html>


More information about the webkit-unassigned mailing list