C’est moi qui ai rédigé le dernier ticket lié, et ça m’a fait une étrange impression de déjà-vu. À l’époque, en creusant le problème, j’avais découvert un comportement assez bizarre.
En gros, Firefox chargeait autant de favicons que 4 fois le nombre d’onglets ouverts sur ce site web, et recommençait à chaque ouverture ou fermeture d’onglet. https://aggressivelyparaphrasing.me/2022/12/12/why-does-my-l...
Ce problème a été corrigé depuis longtemps, donc soit les symptômes sont similaires mais la cause profonde est différente, soit certaines personnes utilisent encore une vieille version.
WordPress doit vraiment gérer les 404 très lentement. Rien qu’en regardant mes logs, je vois un flux constant de bots qui testent des vulnérabilités sur des URL aléatoires ; dans ces conditions, c’est presque étonnant que ça fonctionne correctement.
C’est un projet open source, et il y a une bonne discussion sur GitHub autour des aspects techniques[1]. Cela peut aussi être lié à certains comportements utilisateurs, comme garder des centaines d’onglets ouverts, mais la complexité d’embarquer un navigateur dans iOS doit clairement jouer un rôle.
C’est un peu comme essayer de piloter une pelleteuse dans un bac à sable.
[1] https://github.com/mozilla-mobile/firefox-ios/issues/12113
Je me demande aussi comment ce genre de requêtes peut aller jusqu’à mettre un serveur web à genoux. Elles demandent le flux et le favicon, deux choses qui peuvent être mises en cache via un CDN.
Même sans cache, j’ai du mal à imaginer que le trafic soit si élevé comparé à une autre page qui devient populaire sur HN. C’est du gaspillage, oui, mais ça ne me semble pas si catastrophique.
Même avec des centaines d’onglets Chrome ouverts, ça n’arrive absolument pas. Et si on laisse accidentellement des centaines d’onglets ouverts dans Safari sur iOS, ça n’arrive pas non plus.
J’aimerais qu’on évite de rejeter sur l’utilisateur ce qui est clairement un bug de l’application.
Rien qu’en lisant le titre, j’ai pensé aux scrapers LLM et aux bots qui parcourent tout le web. Bientôt, ils tourneront peut-être directement sur l’AIphone.
Je pensais que tous les navigateurs sur iOS utilisaient le moteur de navigateur d’Apple, et qu’il en allait de même sur Android.
Autrement dit, je croyais que ce n’étaient que des skins.
Je pensais que Firefox sur iOS n’était qu’un Safari relooké, puisqu’Apple n’autorise pas d’autres moteurs de navigateur sur ses téléphones.
Firefox sur Android est excellent grâce à la prise en charge des plugins, même si je préférais quand même l’interface d’avant 2021.
Comme les commentaires voisins sont plutôt négatifs, j’ajoute mon expérience : je ne sais pas ce qui se passe en interne, mais au moins pendant les années précédant la réécriture, j’ai toujours trouvé l’expérience utilisateur de Firefox Android bonne.
Je n’aime pas consulter le web sur téléphone, mais il rendait ça à peu près supportable. Je ne peux pas me prononcer sur les problèmes internes, mais c’est évidemment un sujet qui mérite attention.
Firefox sur Android est une sorte de sauveur pour moi. Le secret, c’est qu’on peut aussi installer uBlock Origin et NoScript sur mobile.
Je suis choqué quand je vois des gens naviguer sur le web sans ces deux-là. C’est absurde de laisser autant de choses accaparer son attention.
Firefox sur Android n’est pas excellent. Pendant des années, son user agent contenait le modèle exact du téléphone.
Ça donne une impression d’incompétence. Correction : ma formulation était un peu dure, et je visais l’entreprise, pas un employé en particulier. C’est exactement la situation que Google souhaite : offrir une dénégation plausible sur les questions de monopole, tout en laissant les alternatives être médiocres.
iOS impose aux navigateurs d’utiliser WebKit fourni par le système d’exploitation, mais ils peuvent utiliser leur propre couche réseau ou injecter eux-mêmes des scripts, comme le feraient des extensions. Orion fonctionne de cette manière.
Firefox pour iOS utilisait autrefois Alamofire comme moteur réseau, puis est passé à un moment donné à NSURLSession/URLSession. Chrome pour iOS utilise Cronet, séparé de la pile réseau de Chromium, mais je ne sais pas si c’est toujours le cas aujourd’hui, car les développements récents n’ont pas forcément été suivis.
Firefox sur iOS est bien un Safari relooké. Cela dit, il évite quand même certains contenus de suivi/publicité, donc il se comporte un peu différemment.
Mais si c’est à ce point problématique, il suffit d’ajouter un favicon. Pour info, je teste souvent avec Firefox sur iOS et je n’ai jamais vu ce phénomène.
L’auteur de ce site fait d’habitude pas mal d’efforts pour masquer le nom des grandes entreprises commerciales quand elles font des choses stupides, mais quand il s’agit de Firefox, il utilise le vrai nom. Hmm.
L’auteur masque le nom de son employeur. Quand il découvre quelque chose en tant qu’utilisateur final, il garde le nom tel quel.
Si le navigateur concerné n’était pas nommé, l’article lui-même n’aurait plus de sens.
Pour quelqu’un qui le lit régulièrement via le flux, ce n’est pas vraiment le cas, et ça n’arrive que dans certains cas précis.
Je me souviens qu’il s’était passé quelque chose de similaire autrefois avec Internet Explorer. Il demandait le favicon, mais comme il n’était pas configuré à l’époque, une page 404 était renvoyée, et cela semblait déclencher à nouveau une requête de favicon.
C’est intéressant. Du seul point de vue de l’expérience utilisateur, Firefox pour iPhone est vraiment une excellente application, et c’est mon navigateur préféré depuis plusieurs années.
Même si c’est en pratique un skin de Safari ?
Le favicon ne fait pas partie de chaque répertoire. Si c’était le cas, ce serait une conception idiote.
Un favicon par chemin ressemble en fait à une fonctionnalité.
Aujourd’hui, c’est assez simple si l’on définit une balise qui indique l’icône. Ce n’est pas la même chose que de s’attendre à ce que le fichier soit au bon emplacement.
Peux-tu donner au moins quelques cas d’usage où un favicon par chemin serait nécessaire ?
Il y a longtemps, j’avais implémenté ça avec pragma no-cache et une vérification du référent. Ce n’était pas parfait, mais ça fonctionnait pour la plupart des utilisateurs.
1 commentaires
Commentaires sur Hacker News
C’est moi qui ai rédigé le dernier ticket lié, et ça m’a fait une étrange impression de déjà-vu. À l’époque, en creusant le problème, j’avais découvert un comportement assez bizarre.
En gros, Firefox chargeait autant de favicons que 4 fois le nombre d’onglets ouverts sur ce site web, et recommençait à chaque ouverture ou fermeture d’onglet.
https://aggressivelyparaphrasing.me/2022/12/12/why-does-my-l...
Ce problème a été corrigé depuis longtemps, donc soit les symptômes sont similaires mais la cause profonde est différente, soit certaines personnes utilisent encore une vieille version.
C’est un projet open source, et il y a une bonne discussion sur GitHub autour des aspects techniques[1]. Cela peut aussi être lié à certains comportements utilisateurs, comme garder des centaines d’onglets ouverts, mais la complexité d’embarquer un navigateur dans iOS doit clairement jouer un rôle.
C’est un peu comme essayer de piloter une pelleteuse dans un bac à sable.
[1] https://github.com/mozilla-mobile/firefox-ios/issues/12113
Même sans cache, j’ai du mal à imaginer que le trafic soit si élevé comparé à une autre page qui devient populaire sur HN. C’est du gaspillage, oui, mais ça ne me semble pas si catastrophique.
J’aimerais qu’on évite de rejeter sur l’utilisateur ce qui est clairement un bug de l’application.
Autrement dit, je croyais que ce n’étaient que des skins.
Je pensais que Firefox sur iOS n’était qu’un Safari relooké, puisqu’Apple n’autorise pas d’autres moteurs de navigateur sur ses téléphones.
Firefox sur Android est excellent grâce à la prise en charge des plugins, même si je préférais quand même l’interface d’avant 2021.
Je n’aime pas consulter le web sur téléphone, mais il rendait ça à peu près supportable. Je ne peux pas me prononcer sur les problèmes internes, mais c’est évidemment un sujet qui mérite attention.
Je suis choqué quand je vois des gens naviguer sur le web sans ces deux-là. C’est absurde de laisser autant de choses accaparer son attention.
Ça donne une impression d’incompétence. Correction : ma formulation était un peu dure, et je visais l’entreprise, pas un employé en particulier. C’est exactement la situation que Google souhaite : offrir une dénégation plausible sur les questions de monopole, tout en laissant les alternatives être médiocres.
Firefox pour iOS utilisait autrefois Alamofire comme moteur réseau, puis est passé à un moment donné à NSURLSession/URLSession. Chrome pour iOS utilise Cronet, séparé de la pile réseau de Chromium, mais je ne sais pas si c’est toujours le cas aujourd’hui, car les développements récents n’ont pas forcément été suivis.
Mais si c’est à ce point problématique, il suffit d’ajouter un favicon. Pour info, je teste souvent avec Firefox sur iOS et je n’ai jamais vu ce phénomène.
L’auteur de ce site fait d’habitude pas mal d’efforts pour masquer le nom des grandes entreprises commerciales quand elles font des choses stupides, mais quand il s’agit de Firefox, il utilise le vrai nom. Hmm.
Je me souviens qu’il s’était passé quelque chose de similaire autrefois avec Internet Explorer. Il demandait le favicon, mais comme il n’était pas configuré à l’époque, une page 404 était renvoyée, et cela semblait déclencher à nouveau une requête de favicon.
C’est intéressant. Du seul point de vue de l’expérience utilisateur, Firefox pour iPhone est vraiment une excellente application, et c’est mon navigateur préféré depuis plusieurs années.
Le favicon ne fait pas partie de chaque répertoire. Si c’était le cas, ce serait une conception idiote.
Un favicon par chemin ressemble en fait à une fonctionnalité.
https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes...
pragma no-cacheet une vérification du référent. Ce n’était pas parfait, mais ça fonctionnait pour la plupart des utilisateurs.Quelques suggestions pour désactiver complètement les requêtes de favicon se trouvent sur https://stackoverflow.com/q/1321878/961353.
J’utilise Firefox sur iPhone. Désolé.
Mais je suppose que je gaspille probablement moins d’énergie qu’en bricolant des trucs avec de l’IA générative.
Pour ceux qui veulent chercher le bug, voici l’emplacement du code : https://github.com/mozilla-mobile/firefox-ios/tree/main/Brow...