Firefox 111 disponible, avec essentiellement le support des notifications natives de Windows
Le 16 mars 2023 à 06h15
1 min
Logiciel
Logiciel
La nouvelle mouture du navigateur ne contient cette fois pas grand-chose à se mettre sous la dent. C’est souvent le cas avec Firefox, alternant les versions riches en nouveautés et celles beaucoup plus calmes, en fonction de ce qui est prêt dans le chaudron des développeurs.
L’apport principal est la bascule sur les notifications natives de Windows, plutôt que par son propre système intégré. On note également la possibilité, pour les personnes utilisant Firefox Relay, de créer des masques email directement depuis le gestionnaire d’identifiant, ainsi que quelques nouvelles langues.
Firefox 111 colmate aussi sept failles critiques et six failles moyennes. Il est donc recommandé d’appliquer rapidement la mise à jour.
Comme d’habitude, la nouvelle mouture se télécharge automatiquement. Il suffit alors de redémarrer le navigateur.
Le 16 mars 2023 à 06h15
Commentaires (19)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 16/03/2023 à 08h24
Firefox reste, et de loin, mon brouteur préféré.
Mais là, ils viennent de copier un gros défaut de Chrome (bah des fois, pas le choix) : cliquer sur le bandeau de titre d’une fenêtre Chrome ou Firefox 111 ne l’amène pas au premier plan.
Avec Firefox <111, ça fonctionnait normalement, logiquement, comme avec n’importe quel autre soft.
Contexte : Linux Devuan + KDE + Focus follow mouse, c’est à dire que le simple fait de placer le curseur de souris au dessus d’une fenêtre lui donne le focus. Très pratique pour garder le Z-order inchangé, pour ne pas avoir à faire d’incessant allers-retours de fenêtres au premier plan, faire des copiers-collers, etc. Mais si je clique sur un bandeau de titre en particulier (n’importe quel élément du window manager il me semble en fait), là, ça amène la fenêtre au premier plan. Donc en gros, c’est premier plan quand je veux uniquement.
Plus globalement, j’en ai un peu (beaucoup) marre des ces UI/UX designers des temps “modernes” qui se croient malin en refaisant totalement à leur sauce l’apparence et le comportement de leurs fenêtres/softs. Ça nique totalement la cohérence du système.
Le 16/03/2023 à 09h14
C’est un cas méga spécifique, qui ressemble à une régression.
Tu devrais ouvrir un ticket chez KDE et/ou Bugzilla.
Le 17/03/2023 à 06h59
Sous KDE (22.12.3) & Plasma (5.27.3) et Firefox (111), je ne vois aucune différence, je ne suis pas certain d’avoir bien compris, mais le focus semble bien dissocier de la fenêtre en avant-plan :
Quand je scrolle ou clic milieu, ça scrolle (colle les données dans) la fenêtre sous le curseur, pas dans celle qui est en avant plan.
Je viens d’activer “Le Focus suit la souris”, ça marche aussi très bien, passé une 0.3sec, le clavier est envoyé vers la fenêtre sous la souris, en cliquant n’importe où la fenêtre se met en avant-plan.
Bref ton prb n’est pas lié à Firefox, il se comporte chez moi exactement comme kate ou konsole.
Le 17/03/2023 à 07h09
Est-ce que quand FF111 n’est pas au premier plan, tu arrives à l’y amener en cliquant sur le bandeau de titre ?
Moi non.
La seule appli qui ne voulait pas passer au premier plan avant FF111, c’était Chrome.
Le Focus Follow Mouse marche parfaitement, ça n’est pas le problème. Les clics, copier-coller, “clics molette” fonctionnent très bien, même quand ces appli ne sont pas au premier plan.
Mon hypothèse est que les dév s’amusent, à tort ou à raison, à recoder 100 % du contenu d’une fenêtre alors qu’une partie devrait être laissée à la charge du Window Manager. Résultat, ils passent à côté de certains détails, et le tout perd en cohérence.
On pourrait aussi parler du Flat Design, des boutons qui n’en sont plus, toussa. Mais même si ça n’est pas hors sujet, ça commencerait à faire trop pour cette discussion.
Aller, si je trouve le temps, j’essayerai de faire une capture vidéo du phénomène.
Le 17/03/2023 à 10h17
Kubuntu 22.10 + Plasma 5.25.5 sur X11
Pas de “focus qui suit le souris” pour moi, mais le clic gauche dans la fenêtre qui l’active (et passe le clic) mais qui ne la place pas au-dessus, justement pour garder le Z-order lors du 1er clic.
Mais ça ne concerne pas la barre de titre, qui passe la fenêtre au 1er plan dés que l’on clic dessus.
A ce niveau, rien n’a changé en passant de Firefox 110 à 111.
Si je clic sur sa barre de titre de sa fenêtre, il passe immédiatement au 1er plan.
Mais sur Kubuntu, Firefox est un Snap, possible que ça joue la-dessus.
A ta place j’aurai vérifié s’il n’y avait pas autre chose dans la conf KDE qui pourrait être spécifique à ce type de fenêtre/appli et qui aurai serai devenu actif (ou désactif) lors du passage à FF111 sans que les dev aient eu la volonté d’avoir le comportement que tu décris.
Mais tu as peut-être déjà cherché de ce côté sans succès ?
par exemple dans le menu “actions supplémentaire” de l’icône de FF dans le coin en haut à gauche de la fenêtre de FF dans les paramètres spéciaux de la fenêtre ou de l’appli, s’il y avait un truc à cet endroit, ça pourrait expliquer le côté spécifique “Firefox” ou “Chrome” de ton problème
Le 16/03/2023 à 08h47
J’ai personnellement rien compris à votre soucis
Le 16/03/2023 à 09h16
Je crois qu’il dit que, sur Devuan avec Plasma et un module qui fait qu’il suffit de survoler une fenêtre pour la mettre en avant-plan, FF111 ne se met plus en avant-plan si on clique sur sa barre de titre.
C’est sûr que c’est pas plutôt son module « Focus follow mouse » qui est en cause, ici ?
Le 16/03/2023 à 10h06
Ah oui ! Je comprends. C’est pas du standard Firefox. Effectivement, ça doit être son module
Le 16/03/2023 à 10h22
Gaffe lors de la migration de la version 110.0.1 à la 111.0 : sur deux PCs, j’ai du réparer mon profil.
Configs de PCs assez similaires (mais pas identiques) : CPU AMD avec GPU AMD, Windows 10 Pro 21h2, tant pour le portable que le fixe. Toutefois, je pense que la cause provenant surtout du fait que c’étaient deux vieux profils (très vieux même : plus de 15 ans facile pour chacun d’entre eux). Et très probablement de modules encore compatibles avec la version 110.0.1 devenus incompatibles avec la dernière version.
Le 16/03/2023 à 10h32
Le 16/03/2023 à 10h40
On est en 2023 et Firefox ne sait toujours pas demander à l’utilisateur s’il peut redémarrer immédiatement ou s’il faut attendre…
Le 16/03/2023 à 11h04
chez moi FireFox me demande s’il doit télécharger la mise à jour, et si oui il l’installe quand je quitte. Peut-être un problème de config…?
Le 16/03/2023 à 14h58
J’ai la config par défaut, et même si c’était une option changée volontairement, je ne pense pas que quelqu’un choisirait Oui à l’option “Voulez-vous être emmerdé par le processus de mise à jour ?”
Le 16/03/2023 à 15h55
je ne sais plus si je l’ai changé, mais chez moi j’ai les possibilités suivantes :
L’installation automatique / manuelle est sur boutons radio, l’option “quand Firefox n’est pas lancé” est sur checkbox. Je pense que dans ton cas, tu dois être en installation automatique, avec l’option “quand Firefox n’est pas lancé” décoché. Mon installation commence à se faire vieille, je n’ai aucune idée de ce qui est configuré par défaut aujourd’hui. Chez moi je suis sur la 2e option.
Le 16/03/2023 à 16h51
J’ai aussi ce comportement sur Fedora, où si le paquet a été mis à jour pendant l’exécution (et comme chez moi c’est une tâche en cron, forcément il va l’être à un moment même si ce n’est pas mon navigateur principal, genre quand je teste un truc avec) il va se bloquer et exiger la relance.
Là où Vivaldi est complètement transparent et ne dit rien jusqu’au prochain démarrage où je découvre la mise à jour.
Le 17/03/2023 à 09h56
Mise à jour de paquet, je peux me tromper mais ça me semble être un truc côté OS. Dans ce cas, je peux aussi dire que quand j’ai une appli ouverte sur mon téléphone, quand elle se met à jour depuis le store elle va se fermer, même si elle était au premier plan.
De mon côté, je parle d’une mise à jour de Firefox gérée par Firefox, et c’est dans ce contexte que j’avais compris la remarque de Jarodd - d’où le fait que je partage ce que je vois dans ma fenêtre de settings de Firefox. Je ne vois pas pourquoi il faudrait reprocher à Firefox de mal gérer le fait qu’il puisse être mis à jour en arrière plan par l’OS…
Le 17/03/2023 à 10h17
Dans la majorité des cas de paquets mis à jour sur Linux, l’instance actuellement en mémoire continue de fonctionner et ne démarrera sur la nouvelle version qu’à sa relance. Typiquement une mise à jour du kernel n’oblige pas à redémarrer, il ne sera pris en compte qu’au prochain reboot volontaire (ou involontaire en cas de crash évidemment).
De mon expérience, Firefox est le seul logiciel que j’utilise sous Linux qui a ce comportement, à savoir bloquer son utilisation tant que l’instance n’a pas été redémarrée. Donc pour le coup, oui, je le lui reproche car c’est pas le comportement usuel des logiciels sous Linux et je trouve ça dommage de bloquer l’utilisateur. Au même titre que je lui reproche aussi de bloquer la session quand il affiche son panneau de nouvelles features ou d’info. Là où Vivaldi se contente d’ouvrir un onglet avec les nouveautés.
Le 17/03/2023 à 10h25
sur mon Windows, après une mise à jour, Firefox m’affiche… un onglet avec les nouveautés.
C’est peut-être un souci spécifique à la version Linux, à voir si quelque chose a été remonté dans le bug tracker du projet…
Le 17/03/2023 à 12h06
En effet c’est fort possible qu’il y ait un choix de design quelque part. Merci pour le retour d’expérience côté Windows.