Mozilla travaille également à une version de Firefox pour iOS sans WebKit

Nicolas Furno |

Si l’obligation d’utiliser WebKit pour créer un navigateur mobile sur iOS sautait, les concurrents de Safari devraient être prêts à agir vite. Après avoir appris hier que Google travaillait sur un navigateur pour iPhone et iPad basé sur Blink, son propre moteur de rendu web, c’est Mozilla qui fait l’actualité aujourd’hui. De la même manière, la fondation travaille à nouveau sur une version de Firefox pour iOS qui se base sur Gecko, son moteur de rendu maison, au lieu de WebKit.

Google travaillerait sur un navigateur pour iOS basé sur Blink et non WebKit

Google travaillerait sur un navigateur pour iOS basé sur Blink et non WebKit

The Register est encore une fois la source de l’information, qui n’est même pas tout à fait nouvelle. En effet, le site a fouiné dans les issues du projet Firefox pour iOS sur GitHub et il est tombé sur cet élément ouvert en octobre dernier. Il y est question d’ajouter une option dans les réglages du navigateur web pour choisir entre WebKit ou « GeckoView », le nom technique donné par Mozilla à la version mobile de son moteur. C’est notamment elle qui est à la manœuvre côté Android, où Firefox peut tourner sur Gecko sans restrictions particulières.

Sur un iPhone, Firefox exploite WebKit, le moteur de rendu d’Apple, mais ce n’est pas par choix (image iGeneration).

Laurie Marceau, l’une des développeuses de Mozilla, a répondu à une question concernant ce ticket pour noter que ce n’était pas une modification intégrée à la version publique de Firefox pour iOS, mais un changement apporté sur une version interne. Pour l’heure, la fondation Mozilla ne semble pas plus déterminée que Google à se fâcher avec Apple et ces essais semblent limités à un usage strictement interne. Mais si la pomme était forcée d’ouvrir iOS à d’autres moteurs de rendu, Firefox pourrait rapidement abandonner WebKit, comme le suggère le pouce en l’air ajouté par la même Laurie Marceau à un autre commentaire qui suggérait cette possibilité.

L’air de rien, c’est peut-être un changement majeur qui se profile pour les iPhone et iPad. Depuis leur création, les appareils mobiles d’Apple n’ont jamais connu d’autres moteur de rendu que WebKit, ce qui a permis au moteur de Safari de s’imposer « de force » dans le monde du mobile. Sans cette exigence, est-ce que sa part de marché va s’effondrer ? Google et Mozilla ne devraient en tout cas pas hésiter longtemps avant de s’engouffrer dans cette brèche, si elle venait à se former.

avatar TR3NT | 

J'en parlais brièvement dans l'actualité qui disait que Google préparait un Blink pour iOS, mais ça a encore plus sa place ici.

En fait, des employés de Mozilla avaient déjà travailler à porter Gecko sous iOS dans le début des années 2010, je ne sais pas trop pourquoi (ils avaient peut-être cru à une ouverture des règles de l'app store à l'époque ?).
Le repo est toujours là, mais n'a pas été mis à jour depuis 2015: https://wiki.mozilla.org/Mobile/Gecko-iOS / https://hg.mozilla.org/users/tmielczarek_mozilla.com/gecko-ios/

Si vous voulez compiler un vieux Gecko pour un vieux iOS, il y a le projet Xcode et tout ce qu'il faut pour le faire.

avatar toto_tutute | 

Et on connaît la raison pour laquelle Apple mettrait un terme à cette obligation d'utiliser son moteur pour les navigateurs tiers ? Y-a-t-il eu des injonctions de la part d'autorités publiques ? Ou volonté d'ouverture de la part d'Apple ?

avatar r e m y | 

C'est sans doute l'info qui manque ici... dès avril 2022, The Register expliquait que le DMA européen allait probablement imposer qu'Apple abandonne l'obligation d'utiliser WebKit
https://www.theregister.com/2022/04/26/apple_ios_browser/

avatar fte | 

@toto_tutute

"Ou volonté d'ouverture de la part d'Apple ?"

DMA EU.

La volonté d'ouverture n’existe absolument pas chez Apple, tu peux en être certain. Il n’y a que la contrainte légale.

avatar SidFik | 

Une bonne chose peut etre pour le développement des webapp !

Mais je doute qu’apple autorise l’installation depuis un navigateur tiers sans passer par safari…

avatar fte | 

@SidFik

"Mais je doute qu’apple autorise l’installation depuis un navigateur tiers sans passer par safari…"

DMA encore. Ils seront contraints de le permettre.

avatar SidFik | 

@fte

Il existe quand meme le navigateur par défaut dans les reglages, l’embêtant est que les racourcis dans l’écran d’accueil renvoient toujours vers safaris meme en choisissant firefox ou autre comme navigateur par défaut..

avatar fte | 

@SidFik

"Il existe quand meme le navigateur par défaut dans les reglages"

Le soucis n’est pas le navigateur par défaut, le soucis est le moteur web unique imposé que tous les navigateurs doivent utiliser.

Un navigateur déplombé de WebKit sera sans doute la toute première application que j’installerai hors store s’il le faut, mais WebKit et Safari peuvent aller se pendre et crever en ce qui me concerne.

avatar SidFik | 

@fte

J’avais bien compris, c’est justement le sujet de la news

Le problème est que la dma ne forcera pas apple a autoriser les navigateurs à pouvoir installer des raccourcis sur le homescreen ce qui est fondamental pour les webapps

avatar stefhan | 

Donc il y a trois moteurs de rendu : WebKit, Blink et Gecko.
Quelles sont les différences ? Au final l'utilisateur y gagne quoi ?

(J'ai cherché sur le web et pas trouvé d'article expliquant clairement d'où ma question de néophyte...)

avatar debione | 

@stefhan:
Alors je ne pourrait vous répondre sur les différences, par contre l'utilisateur y gagne une concurrence... On sait très bien ce que donne l'absence de concurrence dans le domaine privé.

avatar stefhan | 

@debione

Oui je sais mais cela ne répond pas vraiment à la question…

avatar lmouillart | 

S’il a tout dit : moins de concurrence c'est moins d'innovation, moins de scissions entre contenu et lecteur.

On va faire du contenu pour le navigateur A ou B plutôt que pour une famille de navigateurs donc plus focalisés sur des standards. Le contenu n'est donc pas pérenne, mais également lié à des éditeurs ou constructeurs plutôt qu'a des organisations de normalisation ou standardisation.

Moins de concurrence c'est la suppression forcée de certaines fonctionnalités quand elles vont empiéter dans un des secteurs d'activité d'un des éditeurs : les PWA pour Apple (qui rentrent en concurrence avec son modèle d'App store).
Les filtres publicitaires pour Google (qui rentrent en concurrence avec son activité de régie publicitaire).

Moins de concurrence c'est moins de prise de risques et potentiellement moins d'innovation importante (par exemple la création de rust, l’oxydation de Firefox https://wiki.mozilla.org/Oxidation) qui va avoir un impact sur Chrome, Blink (https://security.googleblog.com/2023/01/supporting-use-of-rust-in-chromium.html) et vraisemblablement sur une amélioration de la sécurité de Chrome (https://www.cvedetails.com/product/15031/Google-Chrome.html?vendor_id=1224)

Il faut de la concurrence c'est nécessaire, et sain.
Qu'un navigateur intègre un client bitcoin, un adblock, que l'autre fasse 3fps de plus pour 3mW de moins ce n'est pas le plus important.

avatar jackhal | 

"Moins de concurrence c'est la suppression forcée de certaines fonctionnalités quand elles vont empiéter dans un des secteurs d'activité d'un des éditeurs : les PWA pour Apple (qui rentrent en concurrence avec son modèle d'App store). Les filtres publicitaires pour Google(...)"

Et même, apparemment, quand elles dérangent l'égo d'une personne, cf ce qui se passe avec l'abandon de JPEG XL par Chrome, avec une étude qualitative complètement foireuse, et un décideur qui a travaillé sur le format concurrent (AVIF) et qui préfère visiblement que ce soit son bébé qui soit favorisé, même s'il est techniquement moins bon (beaucoup plus lent à encoder, lossless pourri, pas de chargement progressif, pas de recompression sans perte des JPEG, compression du bruit assez ratée...)

avatar koko256 | 

@stefhan

Les différences sont assez subtiles. Il peut y avoir des fonctions supplémentaires (des animations en plus, des styles d'éléments html, la gestion du copier/coller). Certains codes JavaScript tournent mieux en fonction des optimisations internes.
L'intérêt pour l'utilisateur est de pouvoir tester plusieurs navigateurs pour un site. Parfois certains marchent mieux que d'autre.
Le problème de l'ouverture est vu que l'utilisateur de base n'utilise que chrome et que cela va pousser les sites à surtout vérifier la compatibilité chrome (comme internet explorer en son temps) mais pas la compatibilité avec la norme. Mais bon, on commence à être habitué.
Sur ce dernier point, j'attends avec impatience la reprise de la norme html/css par les navigateurs car la norme actuelle est très lacunaire.

avatar Jeckill13 | 

@debione

En même Internet Explorer avait son propre moteur de rendu également pendant des années… et il a cassé les bonbons des développeurs web pendant des années sans pour autant apporter une plus valut.

avatar lmouillart | 

C'est justement, car il n'y avait pas assez de concurrence.
Il y aurait eu 10% de pdm pour IE, 10% pour Nescape, 10% pour Opera, 10% pour Omniweb, 10% pour Konqueror, 10% pour lynx, 10 pour w3m, 10 pour Mosaic, 10 pour Netpositive 10 pour Voyager, ça aurait été bien plus compliqué pour un contenu de cibler un seul navigateur et ainsi de se priver de 90% du marché.

avatar DP-Britto | 

Excellente nouvelle pour les utilisateurs de FF sous iOS.

avatar Antwan | 

“Depuis leur création, les appareils mobiles d’Apple n’ont jamais connu d’autres moteur de rendu que WebKit”

Tout le monde a oublié Opéra Mini qui avait réussi à pousser sur le store en 2010 une version avec leur propre moteur partiellement pré-rendu à distance.

avatar TR3NT | 

@Antwan

Certains diront qu'Opera Mini n'était pas vraiment un navigateur web du coup. Ce n'était pas "partiellement" pré-rendu à distance, c'était complètement pré-rendu à distance. Le mobile ne faisait qu'afficher ce que le serveur avait pré-maché (html, css, js, images) de la page.

Sur l'iPhone, Opera Mini n'avait pas de moteur de rendu HTML/CSS/JS.

avatar blogostef | 

Quel est l’interêt en fait pour Mozilla de maintenir un moteur de rendu maison pour iOS ? Et pour les utilisateurs, qu’est-ce que cela apporte réellement ?

avatar fte | 

@blogostef

"Et pour les utilisateurs, qu’est-ce que cela apporte réellement ?"

Du choix.

Le choix d’un autre moteur de rendu qui sera peut-être compatible avec un site qui ne l’est pas avec Safari. Et des sites incompatibles avec Safari et qui se branlent de cette incompatibilité, il y en a plein, en particulier là où l’open source est privilégié. Tels que les services de l’État. Qui sont testé et développé pour Gecko.

avatar blogostef | 

@fte
Pas très convaincant l’argument « Open Source » de Gecko. Il me semble que Webkit remplit aussi ce critère.
À vous lire on repart 20 ans en arrière (avec les sites optimisés Netscape et les autres).

CONNEXION UTILISATEUR