5 ms·

We use a totally separate WKWebView process pool and WKWebViewConfiguration for Private Browsing. From the perspective of the underlying web engine, we're two

We use a totally separate WKWebView process pool and WKWebViewConfiguration for Private Browsing. From the perspective of the underlying web engine, we're two separate browsers.

deleted 11y ago
[deleted]
spankalee 11y ago
Nice. Does that isolate private browsing sessions from each other?
- st3fan 11y ago
  Yes. Also there is ZERO data sharing between Firefox and Safari. Both apps run sandboxed and cannot see eachothers data. Both have their own unique and private bookmark, history, cookie, password management.
anon1mous 11y ago
But on IOS you're not a real browser, are you? In my humble understanding Firefox is just a Safari skin, crippled by the lack of JIT.
- elithrar 11y ago
  IIRC, the new (since iOS 8) WKWebView uses the Nitro JIT engine for JS, unlike the UIWebView of old.
- giovannibajo1 11y ago
  A technical centric view of a browser would focus on the rendering engine. But modern browsers, in their being almost small operating systems, go very far beyond the HTML/CSS/JavaScript rendering engine. I will list a few things that vary between browsers irrespective of the rendering engine: tab handling, incognito mode, extension system/ecosystem, privacy handling, search/url bar/completion, security policies, anti malware strategies, download manager, history management, bookmark management, cross platform syncing, password management. And all these things have a higher impact on the user experience than the rendering engine. All these things might be completely different between Firefox and Safari on iOS. Saying that Firefox on iOS is not "a real browser" is an understatement.
  - arm 11y ago
    Um… based on your stance, I don’t think you meant to call that “an understatement”. ;)
  - ploxiln 11y ago
    Don't be ridiculous, the rendering engine is much more complex and many more lines of code than the GUI features. And browsers have had bookmarks, tabs, and password managers for a decade now. More importantly, the rendering engine is what matters to the "open web", if you care about that. If there's only one rendering engine which "everyone" uses, then websites are designed to the bugs and quirks of that engine, then that engine need not fix any bugs, then those bugs become the de-facto standard. Then users can't use the web from the platform or browser UI of their choice if the only web rendering engine of note doesn't support it.
    - veidr 11y ago
      The engines of a 747 are much more complex and designing them takes many more man-hours of engineering than does designing comfortable and spacious seats. But assuming the engines don't fail to perform correctly, which one do you think 99.9% of passengers care more about?
      - ploxiln 11y ago
        Engines aren't just "correct" or "incorrect", they perform differently. Users switched to Chrome from IE because Chrome was well marketed on a website they already used (google) and was way, way faster than IE. Many also switched on OS X because it was a bit faster, more feature-full, and marketed/perceived as way faster. It wasn't because they loved the Chrome UI. I still regularly have to help "common people" find everything but the new-tab button in Chrome (and every browser). Finally, it's clear that UI/UX designers always say they're making software "more intuitive" and "a joy to use" but no one (except grumpy engineers like me...) know what to click or where stuff is hidden anyway. It's all just UI churn, around in circles. Show feature prominently because users don't know how to find it, then hide it because the UI is too cluttered. Repeat. EDIT: and all that's not the main point, sorry ... anyway, the "mass market" or "common" user's ignorance doesn't change the importance of the engine to the "open web". And don't forget how Firefox started, with only particularly savvy users caring to install it.
- st3fan 11y ago
  We are a real and unique browser. Not a Safari skin. There is no such thing as a Safari skin. Instead we use a low level component called the WKWebView, which is a bare-bones minimal API to 'show web pages'. On top of that we have built a browser. This is exactly what Apple has done with Safari. The only common component between Firefox and Safari is the WKWebView. Everything on top of that, like the UI, bookmark management, history, sync is unique and implement in different ways by each browser. Regarding JIT .. the WKWebView exposes the same fast JIT as Safari uses. Run a benchmark. We are as fast as Safari or any other app that uses the WKWebView underneath.
  - klocksib 11y ago
    I think that's what they were getting at though, it's the same engine as Safari with a layer of Firefox on top, not Gecko, etc.
  - ploxiln 11y ago
    Yes as of a few releases ago (but not originally) iOS allows JIT for WKWebView. But no, the result of a bit of chrome (historical name for browser controls) around a WKWebView is indeed just a Safari skin. The renderer is not some minor detail like how tcp connections are made, it's practically the whole thing! It handles the http/https/websocket connections, the html, css, js, html5 video and audio, canvas, webgl, webrtc (or lack thereof), pointer events, everything that matters. - user of firefox on linux and on android, who never "signs in" to his browser chrome, or saves passwords in the browser, or other ill-advised but marketer-loved things - also developer working on a webrtc application, who has had to explain to users "Chrome on iOS isn't actually Chrome, sorry"
    - calsy 11y ago
      WKWebView != Safari. Safari is built on top of WKWebView. Likewise, Firefox is build on top of WKWebView. Firefox is not built on top of Safari, so your Safari skin statement is incorrect. Its called mobile app development, you work with the APIs provided to you by the OS. Attempting to write your own low level networking and rendering libraries that bypass those provided by OS will simply mean your app is not released on the app store. Should Mozilla not release a browser on mobile cause as its not 'true' to your definition?

We use a totally separate WKWebView process pool and WKWebViewConfiguration for Private Browsing. From the perspective of the underlying web engine, we're two separate browsers.

deleted 11y ago

[deleted]

spankalee 11y ago

Nice. Does that isolate private browsing sessions from each other?

st3fan 11y ago
Yes. Also there is ZERO data sharing between Firefox and Safari. Both apps run sandboxed and cannot see eachothers data. Both have their own unique and private bookmark, history, cookie, password management.

anon1mous 11y ago

But on IOS you're not a real browser, are you? In my humble understanding Firefox is just a Safari skin, crippled by the lack of JIT.

elithrar 11y ago
IIRC, the new (since iOS 8) WKWebView uses the Nitro JIT engine for JS, unlike the UIWebView of old.
giovannibajo1 11y ago
A technical centric view of a browser would focus on the rendering engine. But modern browsers, in their being almost small operating systems, go very far beyond the HTML/CSS/JavaScript rendering engine. I will list a few things that vary between browsers irrespective of the rendering engine: tab handling, incognito mode, extension system/ecosystem, privacy handling, search/url bar/completion, security policies, anti malware strategies, download manager, history management, bookmark management, cross platform syncing, password management. And all these things have a higher impact on the user experience than the rendering engine. All these things might be completely different between Firefox and Safari on iOS. Saying that Firefox on iOS is not "a real browser" is an understatement.
- arm 11y ago
  Um… based on your stance, I don’t think you meant to call that “an understatement”. ;)
- ploxiln 11y ago
  Don't be ridiculous, the rendering engine is much more complex and many more lines of code than the GUI features. And browsers have had bookmarks, tabs, and password managers for a decade now. More importantly, the rendering engine is what matters to the "open web", if you care about that. If there's only one rendering engine which "everyone" uses, then websites are designed to the bugs and quirks of that engine, then that engine need not fix any bugs, then those bugs become the de-facto standard. Then users can't use the web from the platform or browser UI of their choice if the only web rendering engine of note doesn't support it.
  - veidr 11y ago
    The engines of a 747 are much more complex and designing them takes many more man-hours of engineering than does designing comfortable and spacious seats. But assuming the engines don't fail to perform correctly, which one do you think 99.9% of passengers care more about?
    - ploxiln 11y ago
      Engines aren't just "correct" or "incorrect", they perform differently. Users switched to Chrome from IE because Chrome was well marketed on a website they already used (google) and was way, way faster than IE. Many also switched on OS X because it was a bit faster, more feature-full, and marketed/perceived as way faster. It wasn't because they loved the Chrome UI. I still regularly have to help "common people" find everything but the new-tab button in Chrome (and every browser). Finally, it's clear that UI/UX designers always say they're making software "more intuitive" and "a joy to use" but no one (except grumpy engineers like me...) know what to click or where stuff is hidden anyway. It's all just UI churn, around in circles. Show feature prominently because users don't know how to find it, then hide it because the UI is too cluttered. Repeat. EDIT: and all that's not the main point, sorry ... anyway, the "mass market" or "common" user's ignorance doesn't change the importance of the engine to the "open web". And don't forget how Firefox started, with only particularly savvy users caring to install it.
st3fan 11y ago
We are a real and unique browser. Not a Safari skin. There is no such thing as a Safari skin. Instead we use a low level component called the WKWebView, which is a bare-bones minimal API to 'show web pages'. On top of that we have built a browser. This is exactly what Apple has done with Safari. The only common component between Firefox and Safari is the WKWebView. Everything on top of that, like the UI, bookmark management, history, sync is unique and implement in different ways by each browser. Regarding JIT .. the WKWebView exposes the same fast JIT as Safari uses. Run a benchmark. We are as fast as Safari or any other app that uses the WKWebView underneath.
- klocksib 11y ago
  I think that's what they were getting at though, it's the same engine as Safari with a layer of Firefox on top, not Gecko, etc.
- ploxiln 11y ago
  Yes as of a few releases ago (but not originally) iOS allows JIT for WKWebView. But no, the result of a bit of chrome (historical name for browser controls) around a WKWebView is indeed just a Safari skin. The renderer is not some minor detail like how tcp connections are made, it's practically the whole thing! It handles the http/https/websocket connections, the html, css, js, html5 video and audio, canvas, webgl, webrtc (or lack thereof), pointer events, everything that matters. - user of firefox on linux and on android, who never "signs in" to his browser chrome, or saves passwords in the browser, or other ill-advised but marketer-loved things - also developer working on a webrtc application, who has had to explain to users "Chrome on iOS isn't actually Chrome, sorry"
  - calsy 11y ago
    WKWebView != Safari. Safari is built on top of WKWebView. Likewise, Firefox is build on top of WKWebView. Firefox is not built on top of Safari, so your Safari skin statement is incorrect. Its called mobile app development, you work with the APIs provided to you by the OS. Attempting to write your own low level networking and rendering libraries that bypass those provided by OS will simply mean your app is not released on the app store. Should Mozilla not release a browser on mobile cause as its not 'true' to your definition?