Firefox 6: Rumeurs et news sur le développement

[~HP]

Mozilla fait de nombreux tests sur ses produits, mais tous sont des benchmarks soit des mesures sur des configurations standardisées. Or, les utilisateurs n'ont pas des configurations si prévisibles. Chez beaucoup, c'est même un bordel sans nom de logiciels espions, de publiciels, de 23 suites de sécurité (certaines désinstallées en partie) et de quelque 163 plugins et extensions. Et ce sont ces utilisateurs-là qui ont le plus de problèmes (Étonnament...).

L'idée est donc de faire comme les autres navigateurs, en particulier Google Chrome, en créant un système de télémétrie. Le navigateur fait un certain nombre de mesures (mémoire, nombre de GC, efficacité du GC, ...) et les transmet une fois par jour à Mozilla qui les utilise pour des statistiques. Très similaire avec les rapports de crashs qui ont permis de corriger des milliers de bugs depuis Firefox 1.

Le système rapportant les données est actuellement dans Nightly (bug 585196). Taras désire que le plus de monde l'utilise (déjà pour tester l'infrastructure de traitement de ces données!) et donc l'active — c'est désactivé par défaut — en mettant la clé toolkit.telemetry.enabled à true (à l'URL about:config).

Il n'y a pas encore d'interface graphique pour visualiser les données, mais Taras a fait une extension (attention: lien direct!) ajoutant about:telemetry pour afficher les données recueillies.

Perso j'ai beaucoup de problèmes de fuites de mémoire sans avoir le moins du monde le genre de config catastrophique décrite… donc, bon… je pense, qu'une fois de plus, la caricature est facile. Donc, du coup, je pense participer à ces tests avec mes diverses configs (home/work).

[teoli2003]

Il est clair que tout n'est pas dû qu'à des configs catastrophes, mais elles n'aident pas. Ce genre de config ajoutent un bruit "mémoire" cachant les vraies fuites. Il faudra bien redonner le contrôle à l'utilisateur au final.

À noter qu'une ou deux fuites sont corrigées chaque semaine, pas toutes grosses (mais certaines oui), pas toutes n'apparaissant dans tous les cas. Je sens clairement l'amélioration depuis Fx 4 final (et encore plus depuis les Fx 4 bêtas!).

[~HP]

Perso, je n'ai senti aucune amélioration, au contraire, sur plusieurs configs très différentes (notamment en terme d'extensions)…

[teoli2003]

Perso, je n'ai senti aucune amélioration, au contraire, sur plusieurs configs très différentes (notamment en terme d'extensions)…

Mac OS a encore un problème de fragmentation mémoire (jemalloc n'est utilisé que sous Windows et Linux), même de petites fuites peuvent empêcher une page mémoire d'être réutilisée chez moi.

De plus, il suffit d'avoir une grosse fuite spécifique, pas encore réglée, pour masquer les autres améliorations. Si tu as une fuite de 1 Mo/min, tu ne remarqueras pas les 100 ko/h corrigés (chiffres inventés).

Enfin, il y a des sites avec des soucis: ainsi GMail retient des liens sur des objets javascript qu'il n'a plus besoin, empêchant le ramasse-miette de les récupérer. Mozilla a travaillé avec Google (plusieurs devs sont allés dans les bureaux de Google) pour analyser le soucis. Google le corrigera dans la prochaine version de GMail.

Je ne vais quasi jamais sur GMail donc je ne le remarque pas. Ceux qui ont en permanence 3 onglets ouverts sur GMail et l'utilisant à donf auront une grosse conso mémoire. (Ce leak est aussi sur Chrome d'ailleurs)

[~HP]

Mac OS a encore un problème de fragmentation mémoire […]

Je ne suis donc pas concerné…

[teoli2003]

Mac OS a encore un problème de fragmentation mémoire […]

Je ne suis donc pas concerné…

Comme la majorité des devs par le tien

[~HP]

Ouais, ils doivent être plus concernés par les demies-douzaines de crapwares installées que tu caricaturais précédemment

[vulcain]

On va maintenant penser que c'est free qui fait ce site.

C'est « un peu » çà, en fait…
Faudrait déjà comprendre ce qu'est un domaine, avant… non ?!

Je sais que c'est un nom de domaine et un nom de sous-domaine. Je réagissait comme une personne qui elle le sait pas. Elle va lire free.fr (ou monsite.fr) et vas taper cela dans un moteur de recherche et ne retrouveras plus le site et sans compter les personnes ayant une mauvaise vue.
Bref je pensais plus à quelques choses comme cela:

propositions.jpg

Une mise en gras du nom de domaine et une mise couleur noir normal pour les sous domaines, pour le reste du gris.

Avec un changement de couleur quand c'est en https valide (donc soit vert ou bleu) mais là seul le nom de domaine prend la couleur du https pas les sous-domaines. En sécurisé le https prend de la couleur pour mettre en avant le s de https.

On obtient une cohérence entre le bouton d'activité, le https et le nom de domaine.
Car il faut penser aux usagers qui changent régulièrement de navigateurs. Dans les dernières versions le cadenas n'est plus de mise (le pire doit safari où ils ont tellement épurés qu'il n'y a plus de différences entre http et https) et il n'y a pas de consensus entre les différents éditeurs pour signaler de manière uniforme une page sécurisée.

[MacIntoc]

Techniquement, www est également un nom de sous-domaine. Donc à mettre en valeur aussi.

[~HP]

Techniquement, www est également un nom de sous-domaine. Donc à mettre en valeur aussi.

Et poum !

[Zefling]

Techniquement, www est également un nom de sous-domaine. Donc à mettre en valeur aussi.

Perso c'est un sous-domaine que j'aime à faire dégager... Sa rallonge l'URL pour rien.

[MacIntoc]

Peu importe l'utilité :p
Traditionnellement, ça permet simplement de savoir sur quel réseau tu te situe.

[teoli2003]

La norme pour XMLHTTPRequest version 2 a évolué. Gecko a été adapté.

Ainsi les premières versions de la spécification définissaient responseArrayBuffer (implémenté avec le préfixe comme mozResponseArrayBuffer). Disparu dans les dernières versions, il est désormais supprimé de Gecko.

Pour le remplacer, la spec définit de nouvelles méthodes response et responseType, qui ont désormais été ajoutée avec le préfixe moz dans Gecko.

(À noter que, au préfixe près, c'est désormais cohérent avec l'implémentation dans Webkit). Le préfixe devrait être supprimé d'ici quelques jours.

Bug 649133 — Implement XHR2 responseType/response attributes
La spec (XMLHTTPRequest Level 2).

[teoli2003]

Dans l'onglet Plugins du Gestionnaire de modules complémentaires (about:addons), un petit lien invitant les utilisateurs à mettre à jour leurs plugins a été ajouté. Il mêne à la page web PluginCheck de Mozilla.

Cela ressemble à cela:

[MacIntoc]

Y a pas de projet pour que les méthodes getElementsBy* renvoient une NodeList conformément à la norme DOM au lieu d'un HTMLCollection ?