Tout commence avec le lien du jour : https://blog.chromium.org/2024/05/manifest-v2-phase-out-begins.html
Donc, dès le 3 juin, les utilisateurs des pré-versions (Beta, Dev, et Canary) de Chromium/Google Chrome verront un avertissement s'afficher s'ils utilisent des extensions utilisant le Manifest V2. Il n'y a pas de date réellement annoncée quant au retrait total du support de ces API, mais ça devient inéluctable.
C'est une longue histoire, qui date de 2019, et le problème le plus emblématique vient du cas de uBlock Origin : https://github.com/uBlockOrigin/uBlock-issues/issues/338#issuecomment-456134855
Pour résumé, les extensions ne peuvent plus examiner le contenu comme avant. Seules des listes statiques de filtrages sont autorisées. On est parti de très loin, la taille de ces listes était très réduite, ça s'est bien amélioré, mais malgré tout, les différences restent notables.
Je sais que je suis dans ma bulle anti-Google (faut admettre ses travers quand même), mais j'ai eu du mal à trouver des bons arguments en faveur de l'abandon de certaines API nécessaires aux bloqueurs de contenus.
# Bons arguments... pour Google
Posté par Christophe . Évalué à 5.
Pour Google, par contre, on devine les "bons arguments" assez facilement:
[^] # Re: Bons arguments... pour Google
Posté par Tarnyko (site web personnel) . Évalué à 3.
Je pense également que les bons arguments leur sont tellement évidents,
qu'ils leur permettent de faire passer les mauvais en loucedé.
# Propulsera les forks ?
Posté par Tarnyko (site web personnel) . Évalué à 5.
Il serait bon de tracer les "moments-clés" de cette modif technique ; un travail important dans la gigantesque codebase de Chromium.
Il existe plusieurs forks de ce browser, mais la plupart des non-corporate sont morts à cause de l'effort que ça représente. Moi-même j'ai abandonné le mien il y a quelques années, quand les "clients" ont changé ; et je ne sais pas jusqu'à quel point la commu suffirait à en pousser un….
…ou on pourrait juste utiliser Firefox 😉 .
Qu'en pense-t-on par ici ?
[^] # Re: Propulsera les forks ?
Posté par RoyalPanda . Évalué à 5.
FF FTW ! (J'ai un forfait consonne)
[^] # Re: Propulsera les forks ?
Posté par barmic 🦦 . Évalué à 7.
Je suis utilisateur de Firefox depuis toujours et je ne compte pas en changer, mais pour le coup Mozilla est en grande parti responsable du fait que les navigateurs alternatifs utilisent chromium. D'un côté tu as un navigateur clef en main et de l'autre ils ont décidé d'abandonner le packaging de gecko en bibliothèque.
Avant ce choix tu avais des alternatives qui utilisaient gecko et il était un terrain d’expérimentation : je me rappel par exemple d'un outil qui permettait de lancer un site web comme une application (donc pas de profile partagé avec ton firefox, un nom et une icone distincte dans ton gestionnaire de fenêtre,…) c'était très pratique quand tu fais des configuration un peu fine de ton gestionnaire de fenêtres (telle application doit se lancer sur ce bureau avec tel raccourcis, ce raccourcis lance l'application ou lui donne le focus si elle est déjà lancée, etc).
Il me semble que le choix est arrivé à l'époque sombre autour de Firefox 4, quand Firefox est resté endormis alors que Chrome arrivait (temps de release long donc difficile de répondre aux nouveautés du concurrent, mauvaise estimation de la performance de leur navigateur, probablement trop de confiance et l'idée que Google mettrait longtemps avant d'être dans la course,…).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Propulsera les forks ?
Posté par Tarnyko (site web personnel) . Évalué à 2.
Une "webview" , un peu comme avec Electron ou le QtWebEngine?
J'avoue ne jamais m'être demandé pourquoi tous ces frameworks étaient basés sur Blink et jamais sur Gecko…
Penses-tu que ça représenterait un effort insurmontable d'extraire le moteur Web ? (je connais que la tuyauterie de l'autre en face)
[^] # Re: Propulsera les forks ?
Posté par Christophe . Évalué à 4.
Il est possible de réutiliser Gecko dans un autre contexte, mais c'est beaucoup de travail…
Par exemple, c'est le moteur utilisé par Jolla dans SailfishOS. Et la difficulté d'intégration n'est certainement pas étrangère au fait que la version utilisée par Jolla est rarement mise à jour !
Un contributeur externe s'est d'ailleurs essayé (avec succès, bravo !) à cet exercice, pour passer Gecko de ESR 78 à ESR 91. Il y a passé quasiment un an sur son temps libre.
[^] # Re: Propulsera les forks ?
Posté par Tarnyko (site web personnel) . Évalué à 3. Dernière modification le 31 mai 2024 à 15:53.
Oh la vache.
Y a d'avoir matière à lecture, le genre de truc épique qu'on oublie pas… ça augure pas du meilleur pour ma question par contre !
Je viens de regarder de mon côté, mon repackaging de Chromium avait pris en gros 3 mois (entre ça et ça). Mais je le faisais en projet pilote… et je trouvais déjà ça beaucoup trop long !
[^] # Re: Propulsera les forks ?
Posté par barmic 🦦 . Évalué à 6.
Plus haut niveau. J'ai oublié le nom de l'outil, mais tu faisais quelque chose comme :
et t'avais un linuxfr dans une fenêtre dédiée.
Histoire de quand même donner des références. Le choix a était fais en 2011 et pour l'exemple Camino qui a toujours était un navigateur gecko n'a pas eu d'autres choix que de passer à webkit (à l'époque blink n'existait pas).
J'ai un peu de mal maintenant quand Mozilla se plains que tout le monde passe à blink/webkit d'ignorer qu'ils en ont était acteur.
C'est pire parce que cette politique n'a pas aidé à ce que node utilise gecko/spidermonkey et a avoir de l'outillage pour les développeurs js avec autre chose blink/v8. Alors qu'ils ont prophétisé l'explosion des usages à l'époque où ils ont créé xul.
Pas vraiment mais apparemment suffisamment pour que Mozilla abandonne.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Propulsera les forks ?
Posté par antistress (site web personnel) . Évalué à 3. Dernière modification le 01 juin 2024 à 03:08.
Ha oui, j'avais pas cliqué sur les liens, merci de me les avoir resignalés.
Du lien sur arstechnica :
Tiens c'est marrant, c'était le but de WebKit 2 qui a succédé sans problème apparemment à Webkit 1 dans les bibliothèques et logiciels de mémoire (par exemple dans WebKitGTK)
J'imagine que l'explication est à chercher en amont :
Ce que l'autre lien semble confirmer :
Et aussi dans le fait que "Firefox OS est dévoilé publiquement en février 2012" (wikipédia) donc déjà en préparation en mars 2011 mais cela ne pouvait sans doute être dit (Firefox OS a nécessité bcp de nettoyage du code de Firefox de mémoire).
Quant à :
j'imagine que ça n'a plus été une priorité depuis
[^] # Re: Propulsera les forks ?
Posté par antistress (site web personnel) . Évalué à 4. Dernière modification le 31 mai 2024 à 16:48.
De mémoire c'est pas si simple, car la réutilisation de Gecko a toujours été complexe comparé à WebKit d'après ce que j'ai pu lire à l'époque (où j'utilisais également Nvu de Daniel Glazman par exemple, et je crois que c'est lui qui l'évoquait).
Du coup à un moment les conclusions ont été tirées par Mozilla.
D'un autre côté, était-il réaliste pour Mozilla d'investir pour rendre Gecko réellement réutilisable, je n'en sais rien.
Et puis là en ce moment tu as Servo qui est peu financé, alors que c'est conçu pour être le plus réutilisable qui soit (https://www.phoronix.com/news/Servo-Engine-May-2024)
Et pour autant Thunderbird se base sur Gecko à chaque ESR…
[^] # Re: Propulsera les forks ?
Posté par barmic 🦦 . Évalué à 6.
J'ai donné le lien plus haut de l'explication de la personne qui le maintenait.
C'est un choix de leur part, ils voyaient Firefox se faire tailler des croupes et ça leur prenait du temps. Ils ont fait un choix. Tel un Lannister ils ont payé leur dette.
Investir sur rust, sur servo, sur boot2gecko, sur FirefoxOS pour le téléphone entièrement web c'était aussi des choix. On peut aussi imaginer que si le packaging de gecko avait était amélioré, l'étape quantum aurait peut être était plus simple. Parce qu'il est plus facile de remplacer quelque chose qand le contrat est proprement défini.
Nous ne le sauront jamais.
Sais-tu où sont les sources de thunderbird ? Pendant longtemps au même endroit que les sources de firefox. Grosso modo tu avais un
make firefoxet unmake thunderbird(ils utilisent pas make mais tu vois l'idée).Aujourd'hui ce n'est plus Mozilla qui chapote thunderbird, du coup c'est 2 dépôt séparé. Tu prends celui de Firefox et tu clone dedans celui de Thunderbird. Bref c'est toujours plus ou moins la même base de code…
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Propulsera les forks ?
Posté par Tarnyko (site web personnel) . Évalué à 2.
Intéressant.
Ça évite du coup aux 2 acteurs (firefox & thunderbird) de définir leurs APIs, ce qui est "visible" et qui ne l'est pas, ce qui est retourné… tout est partagé, et au pire surchargeable (ou hackable via patches).
[^] # Re: Propulsera les forks ?
Posté par antistress (site web personnel) . Évalué à 3.
Intéressant pour Thunderbird, merci pour l'info 👍
[^] # Re: Propulsera les forks ?
Posté par Tarnyko (site web personnel) . Évalué à 5.
Cette ambition m'inquiète d'autant plus que dans l'état actuel, il n'arrive pas à afficher correctement la page d'accueil Google.
C'est le projet auquel il me plairait le plus de contribuer cela dit.
Je m'inquiète éventuellement de la mesure où ces "ambitions affichées", forcément conçues comme un appât à investisseurs, pourraient se mettre sur le chemin du travail réel d'un développeur. Et si la base de code peut réellement fonctionner telle qu'elle est conçue… j'y réfléchis.
[^] # Re: Propulsera les forks ?
Posté par Christie Poutrelle (site web personnel) . Évalué à 2.
Perso j'utilise Firefox à 99%.
Le 1% qu'il reste, c'est pour tester de temps en temps les sites que je développe. Et une fois tous les 6 mois je consulte une vieille boîte gmail.
# La bonne combinaison
Posté par cg . Évalué à 7.
L'argument mis en avant, c'est de renforcer la vie privée et augmenter la sécurité, en limitant les possibilités des extensions d'espionner et de modifier le contenu des pages et les requêtes reçues/envoyées. En soi, ok, c'est un argument qui peut s'entendre. Mais exit le contrôle de ce qu'on reçoit et voit.
Mais quand on combine ça avec d'autres technologies et paramètres comme Encrypted Client Hello, ou le DNS sur HTTPS qui va requêter chez Google, finalement, la visibilité sur le contenu et le trafic n'est laissée qu'aux CDNs et à l'hébergeur (qui est souvent un GAFAM ou en dépend). Exit les pi-holes et les proxy pour nettoyer le caca.
On peut certes s'en sortir en faisant des circonvolutions et contourner l'obstacle, mais l'utilisateur Ⲗ se lassera vite et lâchera l'affaire.
Et en vrai, la navigation web sur ordi, c'est secondaire, de nos jours. L'arpentage se fait sur mobile, et souvent par des applications dédiées, limitantes et fermées par conception.
Le seul truc qui me console, c'est que peut-être que ça donnera un regain de vitalité à Firefox.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.