3 ms·

Why having a separate application with these features instead of adding them to Firefox for iOS ? Is it planned to have content blockers support in Firefox for

Why having a separate application with these features instead of adding them to Firefox for iOS ? Is it planned to have content blockers support in Firefox for iOS ?

deleted 10y ago
[deleted]
st3fan 10y ago
It is complicated. Here is the story of two WebView implementations in iOS: Firefox is based on the WKWebView. Modern and Fast, but has a very poor (thin) API. It has zero options for interacting with the network stack, which is a requirement for content blocking. Bugs have been open since iOS 8, Apple does not seem to be interested or does not have the resources to surface more API. All the APIs are in WKWebView, just private. Focus uses the older UIWebView. Slow, but better ability to interact with the network layer. Not ideal, but at least it is possible. So to answer your question: We would have to replace WKWebView in Firefox for UIWebView. We've been very close to doing this in some form. But it is is big compromise in terms of functionality and stability. So I am not sure when and in what form that will happen. Stuck between a rock and a private API.
- gosukiwi 10y ago
  That's pretty ridiculous for Apple, I understand they make it for safety purposes but they can't deny it also gives them an unfair software advantage. Kind of like old Microsoft and it's private undocumented APIs.
- atarashi 10y ago
  There is a way to interact with the network latyer even when using WKWebView. Since iOS9 there are the Network Extension APIs which allow you to access (and modify/filter) raw packet data. For example: https://developer.apple.com/reference/networkextension/neappproxyprovider https://developer.apple.com/reference/networkextension/neapp...
  - st3fan 10y ago
    Yeah we know these things exist. I just don't think using a VPN or a global Network Extension or a global HTTP interception is a good solution. It would be a workaround. We need a real solution. We need better WKWebView APIs. The requests are known. The bugs have been open since iOS 8. Two years.
- zapu 10y ago
  Is either able to use JIT for JavaScript engine or is it only enabled for Apple's "blessed-process" iOS Safari?
  - st3fan 10y ago
    Only the WKWebView gets fast JavaScript. Any app that uses it will inherit that functionality. For example, Firefox for iOS ranks exactly the same as Safari in speed benchmarks.
  - eridius 10y ago
    WKWebView executes out-of-process just like Safari and so it performs just as well. In fact, that's the whole reason that WKWebView exists (instead of just using UIWebView).
- brendoncrawford 10y ago
  Thanks for explaining this in simple terms. I have been curious about this for a while.

Why having a separate application with these features instead of adding them to Firefox for iOS ? Is it planned to have content blockers support in Firefox for iOS ?

deleted 10y ago

[deleted]

st3fan 10y ago

It is complicated. Here is the story of two WebView implementations in iOS: Firefox is based on the WKWebView. Modern and Fast, but has a very poor (thin) API. It has zero options for interacting with the network stack, which is a requirement for content blocking. Bugs have been open since iOS 8, Apple does not seem to be interested or does not have the resources to surface more API. All the APIs are in WKWebView, just private. Focus uses the older UIWebView. Slow, but better ability to interact with the network layer. Not ideal, but at least it is possible. So to answer your question: We would have to replace WKWebView in Firefox for UIWebView. We've been very close to doing this in some form. But it is is big compromise in terms of functionality and stability. So I am not sure when and in what form that will happen. Stuck between a rock and a private API.

gosukiwi 10y ago
That's pretty ridiculous for Apple, I understand they make it for safety purposes but they can't deny it also gives them an unfair software advantage. Kind of like old Microsoft and it's private undocumented APIs.
atarashi 10y ago
There is a way to interact with the network latyer even when using WKWebView. Since iOS9 there are the Network Extension APIs which allow you to access (and modify/filter) raw packet data. For example: https://developer.apple.com/reference/networkextension/neappproxyprovider https://developer.apple.com/reference/networkextension/neapp...
- st3fan 10y ago
  Yeah we know these things exist. I just don't think using a VPN or a global Network Extension or a global HTTP interception is a good solution. It would be a workaround. We need a real solution. We need better WKWebView APIs. The requests are known. The bugs have been open since iOS 8. Two years.
zapu 10y ago
Is either able to use JIT for JavaScript engine or is it only enabled for Apple's "blessed-process" iOS Safari?
- st3fan 10y ago
  Only the WKWebView gets fast JavaScript. Any app that uses it will inherit that functionality. For example, Firefox for iOS ranks exactly the same as Safari in speed benchmarks.
- eridius 10y ago
  WKWebView executes out-of-process just like Safari and so it performs just as well. In fact, that's the whole reason that WKWebView exists (instead of just using UIWebView).
brendoncrawford 10y ago
Thanks for explaining this in simple terms. I have been curious about this for a while.