Bêta-test Firefox: mes bugs de décembre

Voici les bogues (non liés à mon travail comme employé) que j'ai rapportés ce mois de décembre concernant les versions 3.6 bêta et 3.7 trunk de Firefox.

Bug 532721 - CSS Gradient backgrounds are not repainted when DOM is changed

J'ai trouvé celui là en testant l'un des tutoriels d'Alix de hacks.mozilla.org sur les CSS gradients, la page sur laquelle je travaillais était labs.kompozer.net qui me servait de terrain de test. Ce bogue a été accepté comme bloqueur et les développeurs se sont dépêchés pour qu'un patch soit intégré dans 3.6 :)

Bug 531289 - Firefox doesn't obey system dpi settings anymore

J'ai trouvé ce bogue en testant les compils nocturnes du tronc, c'est une régression sous Gnome/Linux paradoxalement due à une tentative d'amélioration pour Firefox Mobile (Maemo, donc Linux). C'est le bogue typique qui n'est visible que si un grand nombre de testeurs avec des configurations différentes utilisent les compils nocturnes, dans ce cas précis, il fallait avoir réglé les polices de son bureau gnome en dessous de 96dpi pour le voir. Le patch coupable a été corrigé.

Bug 536631 - Firefox no longer detects rss feed

Personne ne s'était apperçu que depuis 3 mois, l'icône des flux RSS n'apparaissait plus dans les versions du tronc uniquement pour Linux. Un bogue similaire avait été rapporté par dbaron qui soupçonnait que cela pourrait poser problème aux applis xulrunner, ce bogue a donc été marqué comme "duplicate" de l'autre et le complète en augmentant son importance, pas encore réparé mais il est maintenantplus sur le radar des développeurs. Ce qui montre que personne n'utilise des versions Linux de Firefox trunk, nul doute qu'une régression aussi visible serait rapportée en quelques heures sous Windows ou Mac.

Bug 534767 - New Drag and Drop JS API does not work with Jetpack installed

J'ai découvert ce bogue en testant la démo de Paul File upload & Firefox 3.6, il s'agit d'une incompatibilité entre Jetpack et notre implémentation de la nouvelle API Drag N Drop d'HTML5, apparemment ça n'affecte que Linux (enfin, j'ai eu la flemme de tester sous Windows...). Il n'est pas clair encore si c'est Jetpack (qui en est en version 0.7 et est encore très vert) ou si c'est un bogue du côté de Firefox, mais a priori c'est un bogue Jetpack donc ça bloquerait pas la sortie de 3.6.

Bug 536843 - Flash plugin has display problems on Firefox Linux Trunk and 3.6 builds, regression

Une régression visuelle pour Flash qui m'énervait depuis 10 jours, bogue saisi il y a trois heures. Grâce au super script regression.py indiqué par Arnaud dans les commentaires de mon précédent billet sur le bêta-test j'ai pu rapidement identifier la date de régression, entre le 1er et le 2 octobre. J'ai trouvé cette régression depuis que j'ai remplacé ma 3.5.* par une 3.6beta 5 comme navigateur principal.

Quelles conclusions tirer de ces exemples ?

1. Il n'est pas nécessaire d'être extrèmement technique pour rapporter des bogues utiles, il ne faut pas penser que c'est réservé à des experts du contrôle qualité, ce n'est pas mon domaine de compétence même si ça m'intéresse
2. Des cinq bogues ci-dessus, quatre sont des bogues ne touchant que la plateforme Linux. On a vraiment besoin que les gens testent réellement les compils quotidiennes de Firefox et les utilisent sur les vrais sites, pas seulement pour tester combien elles font aux tests Sunspider et Acid3... C'est là l'énorme avantage que les versions Windows et Mac ont sur les versions Linux, des tas et des tas de testeurs. Même le nombre de testeurs mac doit être plus important d'un facteur 10 au moins (probablement plus) par rapport à la version Linux. Sans rêver de légions de linuxiens se mettant à la tâche, quelques bons testeurs additionnels et organisés sous Linux pourrait faire une énorme différence sur la qualité de Firefox sous notre OS.
3. Si vous êtes développeur web, il ne faut pas seulement tester ce que vous connaissez (mes sites marchent-ils dans le prochain Firefox ?) mais aussi les nouvelles technologies mises à notre disposition pour avoir une implémentation correcte de celles-ci lors de la sortie du navigateur et donc des nouveaux outils qui marchent tout de suite et pas dans un an après que les gros problèmes auront été réparés.
4. Le contrôle qualité communautaire est probablement un axe d'implication dans le logiciel libre trop méconnu car souvent associé uniquement aux contributeurs les plus techniques. Il y a là un potentiel de travail collaboratif communautaire important pour Mozilla et pour le libre en général. En fait, j'ai même l'impression que l'implication dans le 'bug triage' n'est pas aussi organisée qu'il y a quelques années, j'en suis un bon exemple, je ne suis redevenu réellement actif dans ce domaine que depuis novembre après plusieurs années de faibles activité alors que c'était une de mes activités les plus importantes quand je suis rentré dans le projet vers 2002.