À son tour, Firefox passe en v100, et voici les nouveautés

Antoine Roche

03 mai 2022 à 18h15

25

Après Chrome, l'heure est venue pour Firefox de passer la symbolique barre de la version 100. Il n'y a pas de révolution à trouver sous le capot, mais quelques nouveautés sont malgré tout les bienvenues.

Il s'agit en tout cas de l'une des plus importantes mises à jour majeures du navigateur depuis un moment.

Firefox améliore (notamment) le PiP

L'outil PiP (Picture-in-Picture), qui permet de regarder une vidéo en miniature n'importe où dans le navigateur, s'améliore dans cette version 100 de Firefox. Il supporte les sous-titres et légendes de YouTube, Prime Video, Netflix et les sites web utilisant WebVTT.

Ensuite, l'outil de correction orthographique intégré supporte désormais plusieurs langues, à sélectionner dans le menu contextuel. Firefox 100 prend également en charge les vidéos en HDR sur Mac, à commencer par YouTube.

Côté Windows, les PC compatibles peuvent maintenant utiliser l'accélération matérielle sur les vidéos AV1, et la lecture de vidéos sur des PC équipés de GPU Intel devrait être moins gourmande. Enfin, parmi d'autres éléments mineurs, les utilisateurs peuvent désormais sélectionner des thèmes favoris pour les sites web.

Télécharger

Lire l'avis 8.7

Mozilla Firefox

100 % développé en interne
Fiable, efficace et stable
Fonctionnalités d'optimisation de l'interface et de l'expérience utilisateur

Firefox n’est peut-être pas aussi rapide que Chrome et consorts, mais il n’en reste pas moins un navigateur efficace et fiable. Développée en interne sur tous les fronts, moteurs de rendu et d’exécution JavaScript compris, la solution de Mozilla se veut à la pointe du respect de la vie privée et de la protection de la confidentialité. En témoignent les nombreuses technologies maison intégrées qui contribuent à faire de Firefox un environnement sécurisé (isolation des sites, onglets sandboxés, blocages agressifs des publicités, cookies et traqueurs intersites). Cette liberté d’innovation et d’expérimentation est notamment rendue possible par l’indépendance du projet vis-à-vis de Chromium.

Source : Mozilla

Antoine Roche

Journaliste spé culture pop (séries/ciné/JV), technologie (SVoD, OS, apps…) et jeux de mots douteux. Pas forcément dans cet ordre.

Lire d'autres articles

Journaliste spé culture pop (séries/ciné/JV), technologie (SVoD, OS, apps…) et jeux de mots douteux. Pas forcément dans cet ordre.

Lire d'autres articles

Navigateur web

A découvrir en vidéo

Rejoignez la communauté Clubic S'inscrire

Rejoignez la communauté des passionnés de nouvelles technologies. Venez partager votre passion et débattre de l’actualité avec nos membres qui s’entraident et partagent leur expertise quotidiennement.

S'inscrire

Commentaires (25)

norwy

Un peu déçu par si peu de nouveautés pour un 100ème version…

Felaz

Effectivement, un peu léger la mise à jour…

MattS32

C’est le principe avec les nouvelles versions à intervalle fixe, y a pas vraiment de version plus importante qu’une autre, même si y a un numéro rond, les nouveautés arrivent à mesure qu’elles sont disponibles.

negima

Google et Firefox ne respectent plus le versionnage sémantique depuis qu’ils sont en guerre. Première chose qu’on nous apprend en cours de développeur : version 12.345.678 Le 1er groupe de chiffre c’est une modification majeure. 2e groupe, une modif mineure. 3e groupe, debug. Ils sont censé avoir une version 99.1.0 avant de passer à la version 100.

MattS32

Il n’y a pas qu’une seule règle de versionnage sémantique. Un versionnage sémantique, c’est toute règle de versionnage où le numéro de version n’est pas déterminé arbitrairement, mais selon des règles qui définissent le numéro d’une version en fonction du numéro d’une précédente version et de la nature des changements effectués depuis. D’ailleurs, la règle la plus classique de versionnage sémantique, celle qui a littéralement été nommée « gestion sémantique de version », ce n’est pas celle que tu décris. Il n’y a pas de notion de modification majeur/modification mineure (ce qui au passage est relativement arbitraire hein… une réécriture complète sans aucun changement fonctionnel, c’est majeur pour le développeur, mineur pour l’utilisateur par exemple…), mais simplement une notion de rupture ou non de la compatibilité avec la version précédente : Gestion sémantique de version 2.0.0 | Semantic Versioning Étant donné un numéro de version MAJEUR.MINEUR.CORRECTIF, il faut incrémenter : 1. le numéro de version MAJEUR quand il y a des changements non rétrocompatibles, 2. le numéro de version MINEUR quand il y a des ajouts de fonctionnalités rétrocompatibles, 3. le numéro de version de CORRECTIF quand il y a des corrections d’anomalies rétrocompatibles. Si tu prends un navigateur par exemple (mais le semver se prête en fait assez peu à des logiciels complets, c’est plus adapté à des bibliothèques), il suffit de faire une modification mineure non rétrocompatible, par exemple supprimer le support de la balise HTML marquee, pour que le semver t’impose d’incrémenter le numéro de version majeure. À l’inverse, si tu as un simple viewer de HTML, tu peux le faire évoluer vers une suite Internet complète façon feu Mozilla SeaMonkey, tant que ça sait toujours visualiser un fichier HTML comme la version de base, tu n’incrémentes que le numéro de version mineur. Et tu peux même faire une réécriture intégrale du logiciel, en ne conservant pas une seule ligne de code originale, si tu n’as ni ajouté ni retiré de fonctionnalité, tu ne changes que le numéro de correctif… Un autre exemple de versionnage sémantique classique, c’est celui de libtool, très utilisé pour le versionnage des interfaces de bibliothèques dans le monde Linux, et là encore, pas de notion de changement majeur/mineur, la philosophie est la même qu’en semver, permettre d’après le numéro de version de savoir s’il y a rupture de compatibilité ou pas, mais avec une approche différente, les mises à jour « correctives » ne touchent qu’au deuxième nombre, les mises à jour rétrocompatibles incrémentent le premier ET le troisième (qui est appelé « age », est en fait le nombre d’évolutions fonctionnelles qu’il y a eu depuis la dernière rupture de compatibilité), les mises à jour non rétrocompatibles incrémentent le premier et mettent le troisième à zéro… donc par exemple, si en partant de la 2:0:0 tu ajoutes une fonction et en supprime une, tu passes en 3:0:0, mas par contre si tu fait seulement un ajout tu passes de 2:0:0 à 3:0:1). Quand à la numérotation des versions de Firefox, c’est bel et bien aussi une forme de numérotation sémantique, puisqu’il y a bien une règle stable pour déterminer quel nombre incrémenter à chaque release, ce n’est pas fait de façon « arbitraire » : incrémentation du premier nombre pour les mises à jour fonctionnelles de la version standard, incrémentation du second nombre pour les mises à jour fonctionnelles dans le canal ESR (moment où la version ESR diverge du coup de la version standard, alors que tant que le second nombre est à 0, standard et ESR ont le même code), incrémentation du troisième nombre pour les mises à jour correctives. (et en fait, comme il y a de bonnes chances que chaque version de Firefox casse au moins sur un point la compatibilité avec la version précédente, le versionnage de Firefox respecte sans doute quasiment toujours les règles de semver) En exemple de numérotation qui n’est pas sémantique, je citerai plutôt les très classiques versionnages basés sur la date (par exemple, les versions d’Ubuntu, qui sont en YY.MM), ou encore les plus originaux versionnages utilisés par Donald Knuth pour TeX et Metafont : le numéro de version est pi ou e avec une décimale de plus à chaque version. Là il n’y a effectivement aucune sémantique, on n’a aucune information sur la nature de la mise à jour dans le numéro de version. negima: Ils sont censé avoir une version 99.1.0 avant de passer à la version 100. Et non, ils ne sont pas « censés » avoir une version 99.1.0 entre la 99.0.0 et la 100.0.0. Au contraire, les règles de numérotation de Firefox imposent même qu’il n’y ait PAS de 99.1 entre la 99.0 et la 100.0, puisque le deuxième nombre est réservé aux ESR (et une ESR x.1 n’est pas entre la x.0 et la x+1.0, elle est entre la ESR x.0 et la ESR z.0 avec z >> x + 1). Et d’ailleurs, même en semver ou en libtool, il n’y a jamais de telle obligation… Parce que justement, à partir du moment où tu as une numérotation sémantique, tu ne peux pas imposer d’avoir un certain numéro de version à un moment donné : c’est la nature des modifications qui impose le numéro de version, et tu n’as pas forcément fait de modifications qui mènent à un numéro donné… Par exemple en semver, si après ta version 99.0.0 tu fais une version qui casse la compatibilité, tu DOIS passer en 100.0.0, y a aucune obligation d’avoir eu une 99.1.0 entre temps… Seul une système de numérotation non sémantique peut t’imposer l’existence de certains numéro de version. Par exemple, la numérotation de TeX, oui, elle impose des numéros de version, tu peux pas sortir une 3.1415 après une 3.14, tu dois impérativement avoir fait une 3.141 entre les deux.

toto1234

Si le versionning n’avait pas perdu la tête avec un tel chiffre on serait en 2055…

bmustang

edge est aussi en version 100 et même 101 depuis, c’est plus vraiment une info ?

Yannick2k

c’est vraiment nul ces version qui veulent rien dire! c’est celui qui a plus grosse, c’est moche. par contre, qql1 sait me dire comment virer ces p**** de PiP sous Android ? ça me saoule c’est vidéo qui prennent la place de l’article à lire!!!

MattS32

Yannick2k: c’est vraiment nul ces version qui veulent rien dire! Parce que si le numéro était plus petit, ça voudrait plus dire quelque chose ? C’est quoi un numéro de version « qui veut dire quelque chose » ? Le principal rôle du numéro de version pour l’utilisateur final, c’est de permettre de savoir si on a la dernière version. La numérotation de Firefox permet de le savoir. En rôles secondaires, c’est utile pour le support quand on lui remonte un bug, pour qu’ils puissent tester avec la même version. Là encore, la numérotation de Firefox permet de le savoir. Que demander de plus ?

Necron

Il y a vraiment des gens qui râlent à cause du numéro de version de Firefox ??? Il en faut bien peu pour certains dis-donc …

leulapin

Je suis assez d’accord sur le fait qu’avoir des numéros de version plus en lien avec des sauts technologiques ou l’arrivée de fonctionnalités était plus clair qu’une incrémentation en rolling release comme actuellement. On peut avoir 5 versions avec ajustements cosmétiques et puis une où les perfs sont améliorées de 30% avec changement de moteur derrière super impactante et la numérotation reste la même? Pour des petits projets agiles numéroter en fonction de la date des devs pourquoi pas, pour du progiciel de référence c’est assez pourri comme pratique il faut le dire.

leulapin

Genre les millions de gens dans le monde chargés de maintenir en état de fonctionnement des applicatifs dont la couche de présentation repose sur les navigateurs et qui s’engagent contractuellement à un fonctionnement de l’appli fonction de la version du navigateur ?

MattS32

leulapin: On peut avoir 5 versions avec ajustements cosmétiques et puis une où les perfs sont améliorées de 30% avec changement de moteur derrière super impactante et la numérotation reste la même? Concrètement, pour l’utilisateur, ça change quoi ? Surtout que dans le domaine des navigateurs, on peut quasiment considérer aujourd’hui que toutes les mises à jour sont majeures, car il y a quasiment toujours au passage des correctifs de sécurité… Et là, avoir seulement un 2ème ou 3ème numéro qui change, ça peut pousser l’utilisateur à ce dire « bof, cette mise à jour est pas importante, j’attends la suivante… ». Alors qu’en fait non, elle EST importante. leulapin: Genre les millions de gens dans le monde chargés de maintenir en état de fonctionnement des applicatifs dont la couche de présentation repose sur les navigateurs et qui s’engagent contractuellement à un fonctionnement de l’appli fonction de la version du navigateur ? Ben eux au contraire, ça les arrange, ça les libère de leur engagement contractuel… Parce que si par exemple dans la dernière version de Firefox (donc la 100), il y a un changement qui casse la compatibilité avec une application web, ceux qui étaient engagés contractuellement à être compatibles avec Firefox 99, ben il y a pas de souci, comme c’est plus Firefox 99 ils ne sont pas responsable de la rupture de compatibilité (ce qui dans les fait est la réalité !) et peuvent donc facturer le correctif. Alors que si Mozilla l’avait numéroté 99.1 au lieu de 100.0, ceux qui étaient engagés à être compatibles Firefox 99 devraient faire la correction… De toute façon, fondamentalement, c’est une erreur de prendre un engagement contractuel sur un truc que tu ne maitrise pas… Or le fait qu’une future version du navigateur casse la compatibilité avec une appli web, c’est quelque chose que le développeur de l’appli ne maitrise pas, et que ça soit une x.y.z+1, une x.y+1.0 ou une x+1.0.0 du navigateur n’y change rien… Donc si tu t’engages contractuellement sur une version, tu vas jusqu’au bout, tu met le numéro de version complet dans l’engagement, pas juste le numéro majeur…

Yannick2k

oui mais c’est quand même nul

gamez

merci pour les explications par contre, ils ne sont même pas sensés être à la version 99 ou 100 ces numéros de versions qui défilent c’est du délire. c’est comme si on disait qu’on est sous windows 247.8 xD

MattS32

gamez: ces numéros de versions qui défilent c’est du délire. Non, c’est simplement le principe d’un développement en mode agile, avec des livraisons très fréquentes. gamez: c’est comme si on disait qu’on est sous windows 247.8 xD Oui, et ? Ce serait si gênant que ça ? Microsoft a simplement fait un choix différent dans ses numérotations et de ne pas changer souvent les deux premiers nombres, mais en pratique ça changerait rien que tu sois sous Windows 247.8 ou Windows 10… Par exemple, depuis qu’il sont passés à deux livraisons par an, ils auraient très bien pu décider d’incrémenter le numéro majeur tous les 6 mois, ça ne changerait rien pour nous et ça serait tout aussi valable que ce qu’ils font actuellement, ie incrémenter un numéro de build qui n’a pas plus de sens que le numéro majeur, et qui est même devenu complètement arbitraire, ce n’est plus un « vrai » numéro de build (sur les 10 dernières versions de Windows, ça a fait 16299 → 17134 → 17763 → 18362 → 18363 → 19041 → 19042 → 19043 → 19044 → 22000).

gamez

oui c’est gênant parce qu’on perd la notion de savoir si une sortie est « majeure » ou non. je t’avoue que je préfère télécharger les versions qui apportent un vrai plus. avec le système « codifié/standardisé » de numérotation de version on pouvait savoir si oui ou non ca valait le coup d’installer une nouvelle version lorsqu’on ne veut pas faire de nouvelles installations à chaque fois qu’on a changé la couleur du 3e menu (je n’utilise pas l’update automatique).

MattS32

gamez: je t’avoue que je préfère télécharger les versions qui apportent un vrai plus. Voilà EXACTEMENT le problème que je pointais plus haut et qui à mon sens justifie totalement cet incrément systématique du numéro majeur sur les navigateurs : en distinguant des versions « majeures » et des versions « mineurs », les gens se mettent à zapper les mineures… Or pour un navigateur, qui est un élément critique d’un point de vue sécurité, il FAUT considérer que TOUTES les versions sont majeures justement, parce qu’elles corrigent quasiment toujours des problèmes de sécurité. S’il y a bien un logiciel qu’il faut absolument toujours maintenir à jour, c’est le navigateur. gamez: avec le système « codifié/standardisé » de numérotation de version on pouvait savoir si oui ou non ca valait le coup d’installer une nouvelle version Absolument pas. Parce qu’il n’y a pas un unique système « codifié/standardisé » de numérotation des versions… Et les systèmes qui sont vraiment codifiés/standardisés, comme semver ou libtool, ils ont en général une sémantique qui ne se base pas sur l’importance des changements du point de vue utilisateur, mais sur l’impact des changements du point de vue compatibilité (parce qu’en pratique, c’est bien plus souvent important de pouvoir déterminer de façon automatisée un changement de compatibilité que si une version a beaucoup de changements ou peu). Je n’ai pas connaissance d’un système de versionnage codifié qui se base sur l’ampleur des changements (d’autant plus que, comme je l’ai dit plus haut, l’ampleur des changements, c’est une notion totalement subjective, donc difficile à codifier… un changement mineur pour une personne peut être majeur pour une autre). En semver, tu peux avoir un logiciel qui passe d’un simple viewer HTML à un navigateur complet, tout en n’incrémentant que le numéro de version mineur, alors que le simple abandon du support d’une balise HTML obsolète impliquera un changement du numéro de version majeur…

gamez

d’accord avec tout ça, dans ce cas qu’ils ne parlent plus de versions 99.0.1 suivie de 100.0.0 pourquoi ne pas continuer à incrémenter régulièrement les chiffres à chaque nouvelle sortie. c’est à dire 99.0.1 puis 99.0.2 puis 99.0.3 qu’est ce qui justifie que l’on passe d’un coup à 100.0.0?

MattS32

gamez: qu’est ce qui justifie que l’on passe d’un coup à 100.0.0? Le fait qu’il s’agit d’une mise à jour planifiée, apportant des évolutions dans les fonctionnalités. Alors que 99.0.2, ça serait pour une mise à jour n’apportant que des corrections. C’est comme ça qu’est codifié leur système de versionnage. Le premier numéro est incrémenté à chaque cycle de release de la version standard du navigateur. Chaque cycle de release de la version standard embarque des fonctionnalités, des correctifs de bugs et des correctifs de sécurité. Ce sont des versions planifiées, qui sortent à intervalles réguliers, un cycle de release dure actuellement 4 semaines (on connait déjà les dates de sortie pour les versions 101 à 107). Le second numéro est incrémenté à chaque cycle de correction de la version ESR du navigateur. Un cycle de correction ESR n’embarque que des correctifs de bugs et de sécurité, pas de fonctionnalités. La encore, ce sont des versions planifiées, avec le même cycle de 4 semaines que pour la version non ESR : la ESR x.y.0 sort à la même date que la standard x+y.0.0, et contient les même correctifs, sans les changements de fonctionnalité. Le troisième numéro est incrémenté pour les correctifs urgents. C’est donc seulement lorsqu’il y a un défaut qui doit impérativement être corrigé très vite, sans attendre la fin du cycle (donc faille de sécurité particulièrement grave ou bug fortement gênant…). Là il s’agit de versions non planifiées, on ne connait à l’avance ni leur date de sortie, ni même leur existence. Ainsi, on sait aujourd’hui que la 101.0.0 sortira le 31 mai, qu’il sortira en même temps une ESR 91.10, mais on ne sait pas si entre temps il y aura ou non une 101.0.1 et/ou une ESR 91.10.1 (pas nécessairement les deux à la fois : si le correctif urgent concerne une nouveauté des versions 92 à 100, il n’y aura pas de ESR 91.10.1, si il concerne une fonctionnalité supprimé entre la 92 et la 100, il y aura une ESR 91.10.1 mais pas de 100.0.1) ni à quelle date si jamais elle sort.

leulapin

MattS32: Concrètement, pour l’utilisateur, ça change quoi ? Ca change la possibilité ou non de suivre l’ampleur des évolutions sans lire les logs de toutes les versions précédentes par ex. MattS32: Ben eux au contraire, ça les arrange, ça les libère de leur engagement contractuel… N’importe quoi, quand tu gères un progiciel tu es payé pour que ça marche, qu’un éditeur de middleware te complique la tâche avec du versionning branché yolo ne te relève pas de tes obligations. MattS32: Alors que si Mozilla l’avait numéroté 99.1 au lieu de 100.0, ceux qui étaient engagés à être compatibles Firefox 99 devraient faire la correction… Sauf que si une version est numérotée 99.1 il y a très peu de chance qu’elle casse une quelconque compatibilité si la numérotation reflète l’ampleur du changement. Cette numérotation oblige juste à tout tester en intégralité à chaque MAJ de navigateur et limite donc la fluidité des grands comptes à migrer sur les dernières versions sécurisées puisque quand tu as plusieurs centaines d’applicatifs d’âges différents le résultat obtenu est juste un gel du SI tellement une évolution de navigateur est coûteuse. C’est tellement absurde et sans intérêt comme fonctionnement que Mozilla a été obligé de créer la version ESR à part qui du coup est en 91.9.0 actuellement au max. Ce qui pourrit le fonctionnement BYOD des applis pour un intérêt final… nul à part pour faire la course du numéro de version avec Chrome en mode kikalaplugrosse.

MattS32

leulapin: Ca change la possibilité ou non de suivre l’ampleur des évolutions Le but c’est justement aussi d’éviter ça… Pour éviter que les gens se disent « cette mise à jour est mineure, j’attends la prochaine majeure », alors que chaque mise à jour apporte son lot de correctifs de sécurité et doit donc être appliquée. leulapin: N’importe quoi, quand tu gères un progiciel tu es payé pour que ça marche, qu’un éditeur de middleware te complique la tâche avec du versionning branché yolo ne te relève pas de tes obligations. Tu parlais de quelqu’un qui s’est engagé contractuellement à supporter une version précise de Firefox. À partir du moment où la version change, il n’est donc bel et bien plus engagé. leulapin: Sauf que si une version est numérotée 99.1 il y a très peu de chance qu’elle casse une quelconque compatibilité si la numérotation reflète l’ampleur du changement. Faux. C’est si la numérotation reflète la rétrocompatibilité qu’il y a peu (aucune en fait) de chances qu’une version mineure casse la compatibilité… C’est le cas avec le système semver ou libtool (et en pratique, la numérotation de Firefox, c’est quasiment du semver, parce que de fait, sur un logiciel aussi gros, chaque version a de fortes chances de modifier un comportement et donc de provoquer une rupture de compatibilité). Si la numérotation reflète l’ampleur du changement, tu n’as strictement aucune information sur la compatibilité, car ce n’est pas l’ampleur du changement qui fait qu’il y a rupture de compatibilité, mais bien la nature du changement… Il peut y avoir rupture de compatibilité avec un changement absolument mineur, alors qu’à l’inverse un changement majeur n’implique pas forcément une rupture. Cf l’exemple que j’ai donné plus haut, du simple viewer HTML qui deviendrait un navigateur complet. Avec un versionnage basé sur l’ampleur des changements, il changerait son numéro majeur, alors qu’il n’y a pas de rupture de compatibilité. À l’inverse, l’abandon du support d’une balise HTML obsolète ne changerait que le numéro mineur, alors qu’il y a cette fois rupture de compatibilité… Donc au final, que tu passes de 99 à 99.1 ou à 100, tu dois dans tous les cas te retaper tous les tests, puisque rien ne te garanti que la 99.1 ne casse pas la compatibilité (faut prendre les ESR pour ça, c’est leur rôle). leulapin: C’est tellement absurde et sans intérêt comme fonctionnement que Mozilla a été obligé de créer la version ESR à part qui du coup est en 91.9.0 actuellement au max. Non, c’est indépendant. L’idée de l’ESR, c’est justement d’avoir une branche qui reçoit toutes les mises à jours correctives et de sécurité mais sans les mises à jour fonctionnelles qui risquent de casser la compatibilité. Si Firefox 92 avait été numéroté 91.1 au lieu de 92, ça n’éviterait pas aussi le besoin d’un Firefox 91.1 ESR, 100% compatible avec la 91.0 (ce que ne serait pas la 92/91.1 classique, qui est une mise à jour fonctionnelle), mais avec tous les correctifs de la 92/91.1. Par contre ça rendrait quelque peu compliqué la numérotation, puisque du coup la 91.1 classique et la 91.1 ESR auraient le même numéro, alors qu’elles n’ont pas le même contenu… Quelque soit la façon de numéroter, la seule façon de rendre le même service que l’ESR sans faire une branche ESR séparée, ça serait de ne faire des mises à jour fonctionnelles qu’une fois par an (donc en fait de ne garder que la branche ESR, pas l’autre). Mais ça dans le domaine des navigateurs ça n’est plus viable, tu peux pas te permettre d’attendre un an pour supporter des choses que les navigateurs concurrents supportent déjà. Et en plus, ça permet de tester les nouveautés à plus grande échelle avant de les déployer en entreprise.

leulapin

MattS32: chaque mise à jour apporte son lot de correctifs de sécurité et doit donc être appliquée L’effet inverse est obtenu. MattS32: À partir du moment où la version change, il n’est donc bel et bien plus engagé En concret ça contraint les gens à bloquer les MAJ de navigateurs surtout. MattS32: car ce n’est pas l’ampleur du changement qui fait qu’il y a rupture de compatibilité, mais bien la nature du changement… Il peut y avoir rupture de compatibilité avec un changement absolument mineur, alors qu’à l’inverse un changement majeur n’implique pas forcément une rupture. C’est faux, la plupart des progiciels sont sur des fonctions très standards au coeur des navigateurs, fonctions qui ne sont touchées que par des changements structurels car sinon totalement couvertes par des tests automatisés bloquant les release. Il n’y a quasi pas d’abandons de balises HTML dans l’histoire des navigateurs (< blink >? ), la plupart des fonctions nouvelles justifiant ce rythme de sortie consistent dans le support de nouveaux formats médias, de mécanismes réseau de compression ou de CSS etc. MattS32: Si Firefox 92 avait été numéroté 91.1 au lieu de 92, ça n’éviterait pas aussi le besoin d’un Firefox 91.1 ESR, 100% compatible avec la 91.0 Tu as l’air 100% persuadé que les 9 versions de delta ont cassé une quelconque rétrocompatibilité. Il y a de grandes chances que non (pour du progiciel en tous cas) et c’est ce qui rend ce delta de 9 versions absurde. MattS32: . Et en plus, ça permet de tester les nouveautés à plus grande échelle avant de les déployer en entreprise Pour ça il y a les developper preview, pas les branches « main » grand public des middleware.

MattS32

leulapin: L’effet inverse est obtenu. En es-tu certain ? Perso c’est vraiment pas l’impression que j’ai, bien au contraire, je vois actuellement des navigateurs presque toujours à jour chez tout le monde, ce qui était loin d’être le cas avant… leulapin: En concret ça contraint les gens à bloquer les MAJ de navigateurs surtout. En quoi ça contraint plus qu’avant ? De toute façon avec une numérotation basée sur l’ampleur des nouveautés (ce qui est de toute façon totalement arbitraire comme notion), il n’y a pas plus de garantie qu’un 99.1 est 100% compatible avec ce qui marche sur un 99.0 que de garantie qu’un 100.0 est 100% compatible avec ce qui marche sur un 99.0… Donc celui qui a besoin de rester 100% compatible avec la 99.0, il bloquera dans tous les cas les mises à jour… Encore une fois, une numérotation basée sur l’ampleur des modifications ne dit strictement RIEN sur la compatibilité. leulapin: car sinon totalement couvertes par des tests automatisés bloquant les release. Oui et non. Le moteur de rendu HTML évolue à chaque version vers plus de conformité avec les standards. Mais ça peut casser du coup les logiciels qui tenaient compte d’un défaut de conformité du navigateur et implémentaient un contournement… La release du navigateur ne sera pas bloquée par les tests automatiques (puisqu’elle obtient de meilleurs résultats), mais elle cassera quand même la compatibilité avec certaines applications… leulapin: Il n’y a quasi pas d’abandons de balises HTML dans l’histoire des navigateurs Au niveau des balises HTML, c’est effectivement rare. Il y a par contre des abandons au niveau des protocoles (SPDY, TLS 1.1 par exemple), de certaines fonctionnalités avancées (par exemple le cache manifest pour les web apps), de l’API des extensions, ou encore des protections de la vie privée (quand le navigateur se met à bloquer automatiquement certaines choses, ça fout bien en l’air la compatibilité parfois…). Et surtout, il y a les corrections de bug de rendu, qui de fait peuvent casser la compatibilité avec toutes les pages ayant contourné ce bug… Et il peut aussi y avoir des ruptures de compatibilité au niveau de l’installation, comme c’est d’ailleurs le cas avec Firefox 100, qui ne peut plus s’installer sur un Windows 7 sans la mise à jour KB4474419 (passage d’une signature SHA-1 à SHA-256 pour renforcer la sécurité). leulapin: Pour ça il y a les developper preview, pas les branches « main » grand public des middleware. On parle de Firefox là. Ce n’est pas un middleware. Et les versions développeurs servent pour bénéficier de manière anticipée de nouvelles fonctionnalités qui vont arriver dans le navigateur, pour commencer à développer des pages les utilisant, ça n’est pas comparable à un « test » à grande échelle de nouveautés avant leur déploiement en entreprise…

ben_car

Vue tes problématiques utilise la version ESR elle est faite pour ça.

Voir tous les messages sur le forum

Indépendance
Transparence
Expertise

L'équipe Clubic sélectionne et teste des centaines de produits qui répondent aux usages les plus courants, avec le meilleur rapport qualité / prix possible.

À son tour, Firefox passe en v100, et voici les nouveautés

Firefox améliore (notamment) le PiP

A découvrir en vidéo

Commentaires (25)

Sur le même sujet