Chez Jérémie - Mot-clé - Firefox

Des effets pour le Web

Jeremie — Thu, 12 Jan 2012 09:00:00 +0100

Cet article est la traduction d’un article de Christian « Schepp » Schaefer à propos des nouvelles propriétés de filtres CSS3 et montre comment commencer à les utiliser tout en proposant des solution de repli basées sur ce que supportent les navigateurs actuels.

A la fin des années 90, CSS 2.1 nous a fourni un ensemble d’outils de base pour pouvoir enfin se débarrasser des mises en page en tableaux. Maintenant c’est le tour de CSS3 qui nous donne de nouveaux outils plus précis pour gérer les détails de mise en forme : Les fontes embarquées, les coins arrondis, les dégradés, la transparence des éléments et des couleurs, les ombre portées sur le texte et les boites, etc.

Évidement, lorsqu’on compare notre outillage à celui de logiciels comme Photoshop, on se dit qu’on pourrait rêver mieux. Ce genre de logiciel permet, par exemple, de désaturer une image ou bien de la rendre plus nette ou plus floue. Pourquoi aurions-nous besoin de ce genre d’outil pour le Web ? Et bien, désaturer ou flouter une partie de page Web peut être un moyen de guider le regard de vos visiteurs sur des zones choisies. Ça pourrais aussi aider vos visiteurs à concentrer leur attention sur les zones qui n’ont pas été modifiées. Par exemple, on peut utiliser ce genre d’effets pour mettre en scène une galerie d’images :

D’un autre coté, un effet de netteté peut être utile lorsque vous réduisez une image dans le navigateur. Sans lui, vous allez perdre un certain nombre de détails sur cette image.

Voila, ce serait génial si nous pouvions avoir ce genre d’effets à notre disposition, un peu comme la propriété CSS opacity qui nous permet de rendre un élément transparent. Malheureusement, ce n’est pas le cas.

Le status quo actuel

Au lieu de cela, pour simuler un effet de désaturation/niveau de gris nous sommes actuellement obligés de passer en revue « à la main », via Javascript, toutes les propriétés utilisant de la couleur sur un éléments donnée pour leur attribuer la valeur de gris que l’on veut. Dès que l’on doit faire face à des images ou de la vidéo, c’est encore plus compliqué : Dans ce cas-là, nous avons besoin de nous appuyer sur la balise Canvas de HTML5 pour pouvoir changer leur couleur pixel par pixel puis pour remplacer l’élément d’origine. Même si nous nous appuyons sur des bibliothèques tel que CamanJS ou Hoverizr, ça reste quand même un truc assez sale.

Un effet de flou peut également être simulé à l’aide des propriétés text-shadow et box-shadow en leur appliquant la même couleur que le texte ou l’arrière-plan auquel elles se rapportent. Le problème, c’est que cette illusion ne fonctionnera pas avec les boîtes multicolores non plus qu’avec les images ou les vidéos comme précédemment. Une fois de plus, il faudra se reposer sur des manipulation à base de Canvas HTML5. Arf!

Á propos de la balise Canvas: La bibliothèque blurry.js propose une solution particulièrement brutale à cette histoire de flou. Elle va extraire tout le contenu à flouter, va le recréer dans une balise Canvas (en utilisant partiellement Cufón), va le flouter et enfin va réinjecter le tout à l’emplacement de l’original.

En ce qui concerne la netteté, il n’existe actuellement aucun truc basé sur CSS pour réaliser un tel effet, ce qui nous laisse une fois de plus seul face à la balise Canvas.

SVG à la rescousse

Il est intéressant de noter que SVG connaît la notion de filtres depuis des lustres avec, entre autre, les mélanges de couleurs, l’ajustement de la luminosité et du contraste, les effets d’éclairage, le « displacement mapping », les flous gaussien et de déplacement, le bruit, la netteté, etc.

Ainsi, maintenant que SVG est de plus en plus largement supporté, nous pourrions essayer de placer nos contenus, non plus dans du HTML, mais plutôt dans du SVG que l’on placerait dans du HTML. Nous serions alors capables d’appliquer n’importe quel effet à notre contenu. Le problème, c’est que la plupart des intégrateurs HTML risquent de ne pas être très chauds pour se mettre à produire du balisage SVG de ce genre :

<text font-family="Arial" font-weight="900" font-size="40" x="20" y="55%">SVG Example</text>

Il existe un truc un peu plus sympa en SVG, c’est la balise foreignObject. Elle nous permet d’inclure n’importe quel type de balisage à l’intérieur d’un contenu SVG. C’est un peu comme mettre du SVG directement dans un document HTML5, mais dans l’autre sens. Dès que vous avez inclus vos trucs dans du SVG, vous pouvez y appliquer des filtres comme vous le feriez pour n’importe qu’elle autre partis de votre contenu SVG. Vous pouvez embarquer une page HTML entière et lui appliquer des filtres, ou vous restreindre à une simple image bitmap. Bien sûr, vous devez mettre votre contenu SVG lui-même dans une page HTML, ce qui peut conduire à quelques migraines (du HTML embarqué dans du SVG embarqué dans du HTML). Le support navigateur pour la balise foreignObject est plutôt bon. Seul Internet Explorer reste à la traine. Heureusement, Internet Explorer 10 va rattraper le coup en supportant à la fois les filtres SVG et la balise foreignObject.

Les filtres SVG sur du contenu HTML via CSS

Depuis sa version 3.5, Firefox va encore plus loin. Il vous permet d’appliquer un filtre SVG, défini dans un document externe, à n’importe quel contenu HTML en passant simplement par une feuille de style. Nous pouvons, par exemple, définir dans un document SVG un filtre de flou gaussien (feGaussianBlur) ayant un rayon de 2 pixels et lui donner l’identifiant gaussian_blur :

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" 
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="1" height="1" version="1.1" 
xmlns="http://www.w3.org/2000/svg" 
xmlns:xlink="http://www.w3.org/1999/xlink">
  <defs>
    <filter id="gaussian_blur">
      <feGaussianBlur in="SourceGraphic" stdDeviation="2" />
    </filter>
  </defs>
</svg>

On peut alors référencer ce filtre à l’aide du nom du fichier SVG et de son l’identifiant au sein de notre feuille de style pour l’appliquer à toutes les images :

img {
    filter: url(blur.svg#gaussian_blur);
}

Vous pouvez voir cette démo en live ici. Hélas, comme je vous le disais, ça ne fonctionne qu’avec Firefox.

Bien heureusement, ce n’est pas la fin de l’histoire. Internet Explorer connaît lui aussi les filtres. Ceux-ci ne sont pas basés sur SVG, mais sur des mécanismes propres à la bibliothèque graphique de Windows : DirectX. Parmi ces filtres certains sont bien connus pour nous aider à résoudre certains bugs (le filtre alpha pour les image PNG) ou pour imiter certaines fonctionnalités de CSS3 (le filtre des dégradé). Néanmoins, il en existes d’autres très similaires aux filtres SVG :

/* Flou de 2 pixels de rayon */
filter: progid:DXImageTransform.Microsoft.Blur(pixelradius=2);
/* Flou de mouvement de 13 pixel avec un angle de 310° */
filter: progid:DXImageTransform.Microsoft.MotionBlur(strength=13, direction=310);
/* niveau de gris / désaturation */
filter: gray;
/* Effet « Rayon X » (inversion des niveaux de gris) */
filter: xray;
/* cône de lumière */
filter: light();
/* Extrusion */
filter: progid:DXImageTransform.Microsoft.emboss();

Vous trouverez une liste complète de ces filtres ici : http://msdn.microsoft.com/en-us/library/ms673539(v=VS.85).aspx

Ainsi, à l’aide de commentaires conditionnels, nous pouvons désormais proposer un certain nombre d’effets à deux familles de navigateurs qui à elles deux représente une part non négligeable du marché :

<!DOCTYPE HTML>
<!--[if lte IE 9]> <html class="ie" lang="en"> <![endif]-->
<!--[if gt IE 9]><!--> <html lang="en"> <!--<![endif]-->
<head>
<meta charset="utf-8">
<title>Blur via CSS</title>
<style>
img {
  filter: url(blur.svg#gaussian_blur);
}
.ie img {
  margin: -2px;
  filter: progid:DXImageTransform.Microsoft.blur(pixelradius=2);
  zoom: 1;
}
</style>
</head>
<body>
  <img src="http://jeremie.patonnier.net/post/2012/01/12/stadt.jpg"
   alt="Some rights reserved by zigazou76"
   width="500" height="333">
</body>
</html>

margin: -2px permet de contre balancer le changement de dimension de l’image provoqué par le filtre. zoom: 1 est necessaire pour que la plupart des filtres fonctionnent avec in IE6/7. Malheureusement, IE10 ne supporte plus les filtres propriétaires de Microsoft et n’autorise pas encore les filtres SVG sur du contenu HTML

Vous trouverez ici la version modifié de l’exemple

Un certain nombre de personnes ont apprécié l’idée de Firefox d’ouvrir les filtres SVG au contenu HTML. Ils ont donc formé un nouveau groupe au W3C appelé W3C FX Task Force dont l’objectif est de standardiser et simplifier l’usage des filtres SVG dans tous les navigateurs. Puisque Firefox avait défriché le terrain des filtres d’effets, le premier brouillon de spécification est vite arrivé sous le nom de W3C Filter Effects 1.0. Les mécanismes proposés dans ce brouillon fonctionnent à peu près comme dans Firefox tout en offrant en plus un certain nombre de raccourcis vers les effets les plus intéressants. Les filtres bénéficiant d’un raccourci fonctionnent sans l’aide d’un fichier SVG externe. Ils sont directement codés au cœur du navigateur. Les raccourcis en question sont :

grayscale
sepia
saturate
hue-rotate
invert
opacity
brightness
contrast
blur
drop-shadow

Un autre avantage de ces raccourcis, c’est qu’ils peuvent être animés via les transformations et les animations CSS :

.foo {
  filter: blur(2px);
  transition: filter 1s ease-in-out;
}
 
.foo:hover {
  filter: blur(0);
}

Ce serait plus difficile et moins efficace de réaliser cela dans un document SVG.

Pour finir, les effets de filtre prévois d’être enrichie à l’aide des vertex shaders et fragment shaders d’OpenGL/WebGL. Les vertex shaders permettront d’appliquer un maillage 2D sur un élément que vous pourrez alors déformer en déplaçant tous les points du maillage selon une formule mathématique de votre choix. Les fragment shaders d’un autre côté permettront de réaliser ces transformations mathématiques sur les couleurs de chacun des pixels de cet élément. Ces deux types de filtres bénéficieront en plus de l’accélération matérielle de votre carte graphique.

Par un heureux hasard, il y a quelques semaines les premières implémentations de ces filtres sont apparues dans les compilations nocturnes de Webkit et sont à présent disponibles dans Chrome Canary. Ça veut dire que d’ici 3 mois les filtres CSS seront disponibles dans la version stable de Chrome et à brève échéance dans Safari. Ça veut également dire que nous ne sommes pas loin de pouvoir commencer à utiliser des filtres CSS sur 90 à 95% du marché des navigateurs !

Si l’on en revient à notre exemple, tout ce que nous avons à faire pour supporter Webkit est de rajouter un simple -webkit-filter: blur(2px);. Néanmoins, il faudra faire attention de le placer après la propriété filter non-préfixée. La raison étant que lorsque Webkit supportera la version non-prefixée de la propriété filter, la syntaxe propre à Firefox créra des problèmes avec la transition CSS que nous allons appliquer pour passer doucement entre la version flou et nette de l’image via -webkit-transition: -webkit-filter 1s ease-in-out;.

<!DOCTYPE HTML>
<!--[if lte IE 9]> <html class="ie"> <![endif]-->
<!--[if gt IE 9]><!--> <html> <!--<![endif]-->
<head>
<meta charset="utf-8">
<title>Blur via CSS</title>
<style>
img {
  filter: url(blur.svg#gaussian_blur);
  -webkit-filter: blur(2px);
  -webkit-transition: -webkit-filter 1s ease-in-out;
}
img:hover {
  filter: none;
  -webkit-filter: blur(0);
}
.ie img {
  margin: -2px;
  filter: progid:DXImageTransform.Microsoft.blur(pixelradius=2);
  zoom: 1;
}
.ie img:hover {
  margin: 0;
  filter: none;
}
</style>
</head>
<body>
  <img src="http://jeremie.patonnier.net/post/2012/01/12/stadt.jpg"
   alt="Some rights reserved by zigazou76"
   width="500" height="333">
</body>
</html>

La dernière version de l’exemple

Et voila, des effets de filtres pour tout le monde ! Faisons de 2012 l’année des filtres CSS et amusez-vous bien avec.

SVG et HTML5 font bon ménage avec Firefox

Jeremie — Mon, 26 Jul 2010 15:00:00 +0200

Pour faire suite à mon précédent article sur SVG, je vous propose de partir explorer la révolution technique que représente la possibilité d'inclure du SVG directement dans un document HTML. Cette possibilité fait partie du futur standard HTML 5. C'est une fonctionnalité qui sera disponible dans Firefox 4 et Internet Explorer 9 dès leur sortie. Alors comment ça marche et qu'est-ce qu'on peut en faire ?

Les premiers seront les derniers

Une fois n'est pas coutume, on va commencer par la fin. Dans cette article je vais vous détailler comment j'ai réalisé la démo suivante qui permet de transformer n'importe quelle image ou vidéo disponible en ligne en un Puzzle jouable :

http://jeremie.patonnier.net/experiences/svg/inline/puzzle.html

Pour pouvoir voir et utiliser cette démonstration, vous avez besoin d'un navigateur qui supporte les fonctionnalités suivantes :

Le support de SVG directement au sein des documents HTML5
Le support de la balise canvas
Le support des filtres SVG
Le support des balises clipPath et foreignObject de la norme SVG
Le support de l'API localStorage et de JSON (ça, c'est un peu la cerise sur le gâteau)

Au moment où j'écris ces lignes, le seul navigateur qui réunisse ces conditions nativement est Firefox 4 beta 2. C'est avec lui que j'ai fait tous mes tests.

Vous pouvez aussi tester cette démo avec Firefox 3.6. Néanmoins, pour cela, vous devez activer le support du parser HTML5. C'est possible en vous rendant à l'adresse about:config, en y cherchant le paramètre html5.enable et en lui donnant la valeur true. Attention, il s'agit d'une version expérimentale du parser HTML5 qui n'est pas nécessairement très stable. Pensez à le désactiver une fois que vous aurez finit de jouer (Ceci dit, personnellement, je n'ai jamais eu de problème avec)

A terme, IE9 supportera toutes ces fonctionnalités. Malheureusement, la Plateform Preview 3 ne supporte pas correctement les filtres et comme je n'ai pas de machine tournant sous Windows 7, je n'ai pas pu tester pour voir ce que ça donnait en l'état.

Concernant Safari, Chrome et Opera, je n'ai pas entendu parler d'un support à court terme de SVG directement au sein des documents HTML5.

Mais pourquoi, John ? Pourquoi ?

Avant de détailler comment j'ai utilisé chacune des technologies mise en œuvre, voyons d'abord les raisons des choix techniques fait ici.

SVG directement utilisé dans un document HTML5
D'un coté, SVG va permettre de dessiner assez facilement les formes tarabiscotées des pièces du puzzle. D'un autre coté, HTML est plus facile à manipuler dès qu'il s'agit de mettre en œuvre une interface utilisateur. Le plus simple est donc d'inclure l'un dans l'autre. Techniquement parlant, il est plus facile d'intégrer du SVG dans HTML que l'inverse car on n'a (presque) pas à se soucier de la gestion des espaces de nom XML de SVG et de XHTML, le parser HTML5 s'en occupe tout seul.
Le support de la balise canvas
Prendre une source graphique pour en faire un puzzle requière de la manipuler, à minima pour la découper en morceau représentant les pièces. Dès lors qu'on parle de réaliser des opérations de cette nature, c'est canvas qui est le plus indiqué. En outre, cela permet également de traiter n'importe quelle source graphique supportée par le navigateur en entrée et d'en obtenir une sortie unifiée et manipulable de la même façon, peut importe qu'il s'agisse d'une image ou d'une vidéo (ou même d'une page web quelconque... mais je ne suis pas allé aussi loin ici).
Les filtres SVG
Les filtres SVG permettent d'appliquer très simplement des effets spéciaux sur n'importe quel élément SVG, et, dans le cas de Firefox, sur n'importe quel élément HTML. En outre, les filtres étant déclaratifs (matérialisé sous forme de balises SVG) il est très facile de les modifier et de les ajuster sans avoir à recourir à de complexes artifices de programmation.
Les balises SVG clipPath et foreignObject
La balise clipPath permet de créer des formes de découpes applicables à un objet. Par exemple, si vous voulez "percer un trou" dans une image, c'est exactement ce qu'il vous faut. Si vous vouliez faire la même chose avec canvas, ce serait possible, mais au prix d'un intense effort de programmation sans la souplesse de pouvoir changer simplement la forme de votre découpe. La balise foreignObject permet quand à elle d'embarquer n'importe quoi dans du SVG. En effet, si au sein d'un document HTML5 il est possible de mettre des îlots de SVG, ça ne veux pas dire que vous pouvez mettre du HTML n'importe comment au milieu des balises SVG.
L'API localStorage et JSON
Pas indispensable, mais c'est un moyen simple de pouvoir sauvegarder automatiquement la progression de votre Puzzle.

Bouger ou ne pas bouger, tel est la question

La première chose que j'ai faite c'est de prendre la source graphique qui servira de puzzle et de la redessiner dans un élément canvas. J'utilise cela comme une couche d'abstraction. En effet, une fois la source graphique convertis en un élément canvas, je n'ai plus à m'en soucier et quelques soit les opérations que je ferais par la suite, je me contenterai de manipuler un canvas. Accessoirement, l'opération est d'une trivialité absolue :

monCanvas.getContext('2d').drawImage(maSourceGraphique, 0, 0, maSourceGraphique.width, maSourceGraphique.height);

Néanmoins, ce n'est pas tout à fait suffisant pour gérer les vidéos. En effet, pour que l'élément canvas donne l'impression d'être animé comme la vidéo, il faut redessiner le canvas à intervalle régulière au fur est à mesure de la lecture de la vidéo. Pour cela, il suffit d'utiliser la fonction setInterval pour que la méthode drawImage soit appelée régulièrement.

Une fois que ce premier élément canvas est réalisé, chaque pièce du puzzle comprendra son propre élément canvas dans lequel on dessinera la portion du premier canvas qui lui correspond. Cette double utilisation de l'élément canvas est nécessaire pour 2 raisons :

Question de performance : Sean Christmann a montré dans un article sur l'utilisation des balises video et canvas que l'usage de deux canvas successifs pour réaliser des effets spéciaux sur les vidéos apporte un gain non négligeable vis à vis des performances.
Les limites de l'implémentation de SVG : En théorie, il serait possible de définir un élément canvas réutilisable au sein de SVG. Malheureusement les tests que j'ai pu réaliser mon montrés que ce n'était pas possible. Il faut donc créer un élément canvas distinct pour chacune des pièces.

One piece to rule them all

Chaque pièce du puzzle sera un élément svg à part entière créé sur le même modèle. Cela a plusieurs avantages :

Lors du déplacement des pièces, celles-ci pourront êtres déplacées sur l'intégralité de la surface du document HTML. Si elles avaient été une sous-partie d'un seul élément svg, le déplacement aurait été contraint à la zone visible du document SVG correspondant.
Toutes les pièces reposant sur la même arborescence DOM, il est possible de créer une arborescence générique qui sera clonée autant de fois que nécessaire pour créer toutes les pièces.

L'arborescence DOM d'une pièce de puzzle ressemble à ça :

<svg class="piece" width="155" height="155" x="0" y="0">
    <defs>
        <path id="p1_1" d="M10 10 h100 v26 a23,23 0 1,0 0,48 v26 h-25 a25,25 0 1,1 -50,0 h-25 Z"/>
    </defs>
    
    <clippath id="c1_1">
        <use xlink:href="http://jeremie.patonnier.net/post/2010/07/26/SVG-et-HTML5-font-bon-menage-avec-Firefox#p1_1"/>
    </clippath>
    
    <g>
        <g clip-path="url(#c1_1)">
            <foreignobject x="10" y="10" width="125" height="125">
                <canvas width="125" height="125"></canvas>
            </foreignobject>

            <use xlink:href="http://jeremie.patonnier.net/post/2010/07/26/SVG-et-HTML5-font-bon-menage-avec-Firefox#p1_1"/>
        </g>
    </g>
</svg>

Quelques explications sur cette arborescence :

La balise path est encapsulée dans une balise defs. Grâce à cela la forme de la pièce est masquée et pourra être réutilisée à plusieurs endroit via la balise use. Elle est utilisée une première fois dans la balise clipPath pour définir la forme de découpe de la pièce qui sera appliquée à l'élément canvas. Elle est utilisée une deuxième fois après la balise foreignObject pour pouvoir dessiner un contour autour de la pièce tant que la pièce n'est pas à sa place définitive (pour donner un petit effet de lueur interne sans recourir à un filtre).
La balise foreignObject est entourée de deux balises g. La première (le parent direct de la balise foreignObject) permet d'appliquer la forme de découpe en même temps à l'élément canvas et à l'élément use. La deuxième balise g permet d'appliquer un éventuel filtre d'ombre porté. Si vous appliquez le filtre et la découpe sur le même élément g, le filtre sera appliqué avant la découpe. Si comme ici, vous voulez que le filtre s'applique à la forme résultante de la découpe, vous êtes contraint de sur-baliser votre code SVG pour forcer l'ordre d'application des effets.
Notez l'espace de nom "xlink" sur l'attribut href de la balise use. L'inclusion direct de SVG dans un document HTML5 simplifie drastiquement l'usage des espaces de nom XML mais ne nous en dispense pas totalement. En effet, même dans ce cas d'utilisation, SVG reste du XML et SVG utilisant le langage XLINK pour définir cet attribut href, il est obligatoire de bien spécifier cet espace de nom. Pour éviter d'avoir à faire des manipulations complexes à ce niveau, HTML5 fournis par défaut le raccourcis "xlink" pour gérer cet espace de nom.
Vous noterez que la taille de l'élément svg est plus grande que celle de l'élément canvas. C'est nécessaire car la zone visible de l'élément svg correspond à la portion de la source graphique représentée par l'élément canvas ET les éventuels filtres qui s'y appliqueront pour générer les ombres portées.
La valeur de l'attribut d de la balise path peut faire peur. Je ne vais pas vous détailler ici le pourquoi du comment (ça mériterai un article à part entière) mais sachez juste que c'est cette simple ligne qui fait qu'on a un tracé de pièce de puzzle (ici le coin haut-gauche). Si vous regardez la source du puzzle, vous verrez que j'ai regroupé toute l'intelligence de la construction de ce chemin dans une fonction dédiée. N'hésitez pas à vous amuser à la décortiquer.

T'as d'beaux yeux tu sais !

Pour rendre l'expérience de jeux un peu plus fun, on va rajouter quelques effet spéciaux et fonctionnalités qui vont permettre de lui donner un aspect un peu plus "fini".

Pimp my mouse

L'idée quand on créer des pièces de puzzle qu'on peut manipuler à la souris, c'est de pouvoir gérer la sélection de la pièce selon la forme de celle-ci. Le problème, c'est que si on ne fait rien, la souris régis à une zone rectangulaire, même sur les zones transparentes. Heureusement, de ce point de vue, SVG est bien fichue et sait gérer ça sans avoir à recourir à des dizaines de lignes de code. En fait, ça se résume à un peu de CSS :

svg{
    pointer-events : none;
}

svg canvas{
    pointer-events : auto;
}

La propriété pointer-events permet de définir comment la souris va réagir lors de ses interactions avec un élément. Ici on dit que la souris ne doit pas déclencher d'évènement lorsqu'elle interagit avec un élément svg mais par contre elle doit réagir normalement avec les éléments canvas présent dans nos éléments svg. Comme les éléments canvas sont découpés par un clipPath, seul les parties visibles de l'élément canvas réagiront à la souris (ce comportement est sans doute la principale différence entre les balises clipPath et mask de SVG). Notez que d'un point de vu Javascript, même si la souris ne renvoie pas d'évènement lorsqu'elle interagit avec les éléments svg, les évènements renvoyés par la souris sur l'élément canvas remontent normalement vers l'élément svg est peuvent être interceptés à ce niveau là. La propriété pointer-event ne fait que bloquer l'émission des évènements, elle ne bloque pas leur diffusion ni leur exploitation dans le DOM.

Ombrage, ô désespoirs !

Pour donner un peu de relief au puzzle, je me suis amusé à rajouter des ombres portés sur les pièces : une petite ombre porté quand une pièce est posée n'importe où, une grande ombre porté quand la pièce est "soulevée" et transportée et enfin, pas d'ombre du tout une fois que la pièce est à sa place définitive. Chacune des ombres (la petite est la grande) est définie à l'aide d'un filtre SVG distinct pour chacune. Par exemple, la petite ombre est définie comme cela :

<filter id="smallShadow" filterUnits="userSpaceOnUse">
    <feColorMatrix type="matrix" in="SourceAlpha" result="greySource"
                   values="0 0 0 0 0  0 0 0 0 0  0 0 0 0 0  .6 .6 .6 .6 0"/>

    <feGaussianBlur in="greySource" stdDeviation="2" result="flou"/>
    <feOffset in="flou" dx="1" dy="1" result="Ombre"/>
                
    <feMerge>
        <feMergeNode in="Ombre"/>
        <feMergeNode in="SourceGraphic"/>
    </feMerge>
</filter>

Pour faire simple, ce filtre prend la source alpha (la transparence) de l'élément auquel va s'appliquer le filtre, lui applique une matrice de couleur (feColorMatrix) pour quelle soit noir et légèrement transparente, va la flouter (feGaussianBlur), la décaler (feOffset) vers le bas et la droite et va recombiner le tout (feMerge, feMergeNode) avec la source graphique de l'élément. Je ne vous détail pas plus précisément que ça l'usage des primitives de filtres car cela mériterai un article à lui seul, mais c'est tout ça qui fait qu'on a une ombre de forme arbitraire (contrairement à la propriété CSS box-shadow qui ne produit que des ombres rectangulaires... éventuellement avec des coins arrondis, mais c'est tout).

L'application des filtres se fait très facilement directement via CSS

.shadow > g{
    filter:url(#smallShadow);
}

#drag.shadow > g{
    filter:url(#bigShadow);
}

.lock.shadow > g{
    filter:none;
}

Vous n'avez alors plus qu'à jouer sur les classes est les ID de vos éléments avec Javascript pour appliquer ou non un filtre. Notez que Firefox permet également d'appliquer un filtre SVG à n'importe quel élément HTML. C'est ce que j'utilise pour griser l'aide du puzzle qui n'est qu'un simple élément canvas affiché sur l'aire de jeu auquel j'applique un filtre de matrice de couleur.

Allo ! Caroline ! C'est Roger.

Dernière fonctionnalité, la sauvegarde automatique du puzzle en arrière plan. A chaque fois que vous déplacez une pièce, il y a un appel à l'API localStorage de HTML5 pour enregistrer la position de la pièce. De cette manière, si pour une raison ou une autre vous devez interrompre votre partie, vous pouvez la reprendre plus tard exactement là ou vous vous étiez arrêté.

Pour simplifier les traitements, je stocke toutes les données représentant l'état du puzzle dans un objet spécifique. L'API localStorage stocke les données sous la forme clé/valeur. La norme est assez flou sur le type de donnée qui peuvent être stockées mais Firefox n'accepte que les chaines de caractère comme valeur à stocker donc, pour enregistrer mon objet, je le transforme en chaine en utilisant le support natif de JSON tel que définie dans la norme ECMAScript 5 :

var data = JSON.stringify(this.savedData);

window.localStorage.setItem('currentPuzzle', data);

La récupération des données est tout aussi simple :

var data = window.localStorage.getItem('currentPuzzle');

data = JSON.parse(data);

Parfois, c'est le vil coyote qui gagne

Lorsqu'on manipule des technologies nouvellement implémentées dans des navigateurs qui en sont encore au stade des versions Alpha/Beta, il n'est pas rare que l'on soit confronté à des problèmes. Dans ce cas précis, j'ai travaillé avec Minefield qui est la version non-stable de Firefox (et qui représente au moment ou j'écris ces lignes la version de développement du future Firefox 4) et j'ai été confronté à trois types de problèmes différents.

Is there a Road Runner over here?

Les développeurs de Firefox 4 travaillent actuellement comme des malades sur les performances du navigateur et si l'on peut déjà percevoir une amélioration globale des performances, le travail n'est pas terminé et de nombreuses améliorations sont encore attendues dans les semaines à venir. Malheureusement, tout n'est pas parfait...

Dans le cas qui nous occupe ici, le principal problème de performance provient de l'usage des filtres SVG. Les filtres sont actuellement ultra consommateur de ressources pour pouvoir être calculés. Ils sont tellement gourmands que j'ai très vite mis la possibilité de désactiver les ombres portées sur les pièces. En effet, si vous activez les ombres portées et que vous construisez un puzzle basé sur une vidéo, la lecture de celle-ci sera saccadée et le déplacement des pièces ne sera pas fluide. Le problème sera d'autant plus perceptible si vous créez un puzzle avec de nombreuses pièces (plus de 50) car au problème des filtres vient s'ajouter l'augmentation du nombre de nœuds DOM à gérer ce qui peut très vite plomber l'utilisation du jeu (en particulier lorsque vous déplacez les pièces).

Autre point qui peut vite affecter les performances, l'utilisation de l'API localStorage. L'accès en lecture et en écriture via cette API est prohibitif au niveau performance (un peu moins de 100 milliseconde pour une simple opération d'écriture de chaine de caractère sur ma machine... iiirk !). Ainsi si j'avais voulut enregistrer séparément la position de chaque pièces, il aurait fallut près de 10 secondes pour enregistrer l'état d'un puzzle de 100 pièces ! Soyez donc très prudent si vous utilisez cette API car sinon cela peut vite se voir. Si vous prévoyez de faire beaucoup d'opération via celle-ci, je ne saurait trop vous conseiller soit de les traiter en tache de fond asynchrone via l'utilisation de l'API Web Workers, soit de travailler avec un objet contenant vos données que vous transformerez en chaine JSON avant de l'enregistrer intégralement en une seule fois (c'est cette dernière stratégie que j'ai choisie). Si vous n'y faite pas attention, vous pouvez vous retrouver avec un gel complet de votre page !

Robert ! Il y a un cafard dans la machine.

L'intérêt de réaliser ce genre de démo avec une version de développement d'un navigateur, c'est que ça permet de découvrir des bugs qu'il est possible de faire corriger avant la sortie de la version final du navigateur. Les bugs les plus faciles à corriger sont liés à l'implémentation de la balise SVG foreignObject :

Bug 576986 : la balise foreignObject ne respectait pas les règles d'application des évènements de la souris lorsqu'on lui appliquait une forme de découpe. La correction a été apportée dans les heures qui ont suivit. Waow !
Bug 578309 : La balise foreignObject redéfinissait son propre espace de coordonnées, comme si on y avait appliquée une transformation. La encore, il n'aura fallut que quelques jours pour que ce soit corrigé. J'en profite ici pour adresser un grand merci à Robert Longson qui a travaillé sur ces bugs en particulier et qui fait un énorme travail en ce qui concerne le support de SVG dans Firefox.

Mais il y a aussi quelques bugs plus durs qui vont sans doute être assez délicat à résoudre :

Bug 577824 : Quand on attache un élément HTML à l'arbre DOM du document via Javascript et qu'un filtre s'applique sur cet élément, l'élément n'est pas affiché.
Bug 577464 : Celui là, c'est le plus bizarre de tous, et sans doute le plus difficile à résoudre. Dans certain cas de figure, le rendu des éléments auquel est appliquée une forme de découpe n'est pas correctement réalisé. Il est tellement difficile de produire un cas d'utilisation unitaire que son simple diagnostique risque de prendre du temps. Une des pistes actuellement exploré serait un bug lié à la bibliothèque graphique Cairo qui est utilisée par Firefox pour rendre les éléments visuels.

Allo ! Tonton ? Pourquoi tu tousses ?

Après, au delà des éventuels problèmes d'implémentation, il y a aussi les problèmes liés aux spécifications elles-mêmes. Les spécifications qui tournent autour de HTML5 ne sont pas encore finalisées ou pas forcément adapté à certains cas d'utilisation et l'on tombe parfois sur des perles qui peuvent plonger un web designer dans des affres d'incompréhension. J'en ai découvert deux dans ce gout là. Une dans la spécification de l'API Canvas 2D et une dans la spécification de SVG 1.1.

Canvas pas aller ça monsieur.

En l'état de la spécification, avec la méthode drawImage de canvas, il est possible de dessiner soit une image, soit une vidéo. Quand vous dessinez une image, pas de problème, vous dessinez l'image elle-même. Quand vous dessinez une vidéo, ce qui est dessiné, c'est l'image qui est lut par le lecteur vidéo au moment ou on appel la fonction de dessin. Maintenant, que ce passe-t-il si vous voulez dessiner une image animé (aGIF, APNG, MNG, SVG, etc.) ? Moi, assez naïvement, je me suis dit que ça allait dessiner l'image courante de l'animation au moment ou on appel la fonction de dessin... bref que ça allait ce comporter comme avec une vidéo et c'est d'ailleurs comme cela que se comporte Firefox 3.6. Mais que nenni jeune Padawan ! La spécification dit que dans le cas d'une image animé, ce qui est dessiné, c'est la première image de l'animation et puis c'est tout !

http://www.w3.org/TR/2dcontext/#images

When the drawImage() method is passed an animated image as its image argument, the user agent must use the poster frame of the animation, or, if there is no poster frame, the first frame of the animation.

Et chez Mozilla, ils se sont dit que ce serai une bonne idée de suivre la spécification dans Firefox 4. Résultat des courses, j'ai ouvert un bug en pensant à une régression, mais non, c'est juste qu'ils on fait en sorte d'être respectueux de la spécification.

Alors, là, j'ai envie de dire : "Bravo, c'est bien". Mais d'un autre coté, maintenant, on fait comment pour accéder aux autres images qui composent une image animée ? On est typiquement dans un cas ou la spécification est difficile à comprendre et elle reflète sans doute les capacités des fabriquant de navigateur à gérer ce cas d'utilisation. Mozilla sait comment gérer les images animées dans ce cas de figure, mais se bride du fait de la faiblesse de la spécification sur ce point. C'est dommage.

La spécification n'est pas encore définitive et si vous pensez que ce cas d'utilisation est important, faite le savoir. Pour cela, vous pouvez soit faire du lobbying auprès du HTML Worging Group (bon courage !) soit auprès des fabricants de navigateur qui sont directement parti prenante. La discussion est ouverte chez Mozilla et si, par exemple, vous prenez simplement le temps de voter pour le bug que j'ai ouvert, peut-être que Mozilla considèrera qu'il y a matière à pousser le sujet.

SVG, ou l'art de Se Vautrer la Gueule ?

A la base, j'ai fait une mauvaise interprétation de la spécification SVG alors que je voulais réutiliser un élément foreigObject avec la balise use. J'ai naïvement crus que n'importe quelle enfant légitime de la balise g pouvait être réutilisé via la balise use. Malheureusement, ce n'est pas le cas. La balise use ne peut être utilisée que pour dupliquer des éléments explicitement graphique (ce qui n'est pas le cas de foreignObject) ou certains conteneurs (g, symbol et svg). Néanmoins, comme g est un élément valide pour use, il suffit d'envelopper un élément foreignObject avec un élément g est le tour et joué.

Et là de se poser la question : "Mais pourquoi la norme ne permet pas d'utiliser directement tous les enfants légitimes de g ? Pourquoi faut-il rajouter une balise supplémentaire qui a le gout et l'odeur de l'inutile ?". Bien évidement, il s'agit de questions de web designer, pas d'implémenteur. En effet, il y a fort à parier que lorsque la norme a commencé à être écrite (il y a plus de 10 ans, rappelons-le), les développeurs en charge de sa mise en œuvre ont du rencontrer un problème à ce niveau et faire un arbitrage dans ce sens. Ou bien il y a eu un débat philosophique quelconque a propos de ce qu'est la balise use et personne n'a réussie à challenger cette vision. Franchement, je n'en sais rien mais avec le recul que l'on a désormais, la question aurait le mérite d'être à nouveau posée.

De manière général, ce genre de collision malheureuse entre SVG et HTML5 risque de se représenter ailleurs (essayez de contrôler à l'aide de Javascript une balise HTML video que vous avez cloné via la balise SVG use... vous ne pouvez pas !). En effet, on a d'un coté une norme vieillissante (SVG) et de l'autre une norme toute neuve en construction (HTML5). A bien des égards, SVG a été conçus pour vivre dans un univers statique. A l'inverse, HTML5 redéfinis énormément d'éléments dynamiques au travers de nouvelles API Javascript. De ce point de vue, je ne serais pas surpris que HTML5 redonne un coup de fouet à SVG et il n'est pas exclus que dans les années a venir on voit arriver une norme SVG 2 pour résoudre tous ces nouveaux cas d'utilisation... mais bon, ne soyez pas trop pressé. C'est aussi ça qui fait que Flash à encore de beau jours devant lui.

Le mot de la fin (des haricots)

Voila, je viens de vous arroser avec un article copieusement long et en même temps extrêmement raccourcis. Si vous voulez comprendre plus précisément comme marche quoi, je vous encourage à regarder le code source que j'ai essayé de commenter le plus possible. Ce qu'il faut retenir, c'est que le support de SVG dans HTML est encore quelque chose de très expérimental mais cela donne déjà une bonne idée de ce que peut faire chaque technologie respective et ce que l'on gagne à les mixer.

Si vous voulez aller plus loin, n'hésitez pas à lire les spécifications. Elles peuvent parfois s'avérer très utile. La spécification SVG par exemple comporte de nombreux exemples de code très utile à la compréhension. D'autres ressources très utile également sont les documentations techniques des fabricants de navigateurs. En particulier dans le cas de cette démo, le Mozilla Developper Center, mais aussi MSDN, Opera Dev et le wiki de Webkit.

Quoi qu'il en soit, expérimentez vous même et faite vous votre propre idée. Ces technologies sont toutes assez nouvelles, les implémentations évoluent constamment et le processus de standardisation n'est pas linéaire...mais amusez vous, c'est comme ça que vous apprendrez de nouvelles choses

La spécification SVG : http://www.w3.org/TR/SVG/
La spécification HTML 5 : http://www.w3.org/TR/html5/
- L'API Canvas 2D : http://www.w3.org/TR/2dcontext/
- L'API Storage : http://www.w3.org/TR/webstorage/
- L'API Web Workers : http://www.w3.org/TR/workers/
ECMAScript 5 (PDF) : http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf

Devenir beta-testeur de Firefox sous Ubuntu/Linux

Jeremie — Fri, 19 Mar 2010 09:30:00 +0100

Suite à un article de Pascal Chevrez, qui soulignait qu'il n'y avait paradoxalement pas assez de beta-testeur de Firefox pour Linux, j'ai eu envie de me pencher sur la question de l'installation des beta de Firefox sous Linux (enfin sous ma Ubuntu surtout ). En temps que noob de Linux, ça a été assez intéressant de voir ça.

L'idée de cette article est de fournir un "How-to" pour devenir beta-testeur de Firefox sous Ubuntu (mais ça marche aussi pour les utilisateurs de Windows et Mac OSX, hein !) tout en étant volontairement orienté pour un public peu technique (j'assume le fait que vous sachiez tout de même ce qu'est un répertoire et que vous sachiez au moins ouvrir une fenêtre de ligne de commande, même si vous ne savez pas trop quoi en faire).

Petit préambule technique à destination des utilisateurs non techniques : le raccourci ~/ fait référence à votre répertoire de travail personnel. Le chemin d'accès "long" vers ce répertoire sous Ubuntu est /home/nom-d-utilisateur/.

Télécharger Firefox

La première chose à faire, c'est de télécharger la version de Firefox que vous voulez utiliser. Pour cela, vous trouverez tous ce qu'il vous faut sur les sites de Mozilla. Néanmoins, plusieurs choix s'offrent à vous selon ce à quoi vous vous intéressez :

Vous voulez la dernière version stable de Firefox, rendez-vous ici :
http://www.mozilla.com/en-US/firefox/all.html
Vous voulez tester la dernière beta "public", rendez-vous ici :
http://www.mozilla.com/en-US/firefox/all-beta.html (actif uniquement en période de beta-test des versions majeurs, ce qui n'est pas le cas au moment ou j'écris ces lignes)
Vous êtes un aventurier et vous voulez tester une "nightly build", c'est ici que ça ce passe :
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ (notez qu'il s'agit de l'accès direct au "trunk", mais si vous remontez l'arborescence d'un niveau, vous pouvez accéder à d'autres branches de développements... ah ben oui, là, vous êtes vraiment en mode aventure hein)

Attention pour les utilisateur de Linux 64 bits. En effet, Mozilla ne fournis des versions compilées que pour les systèmes 32 bits. Ça ne vous empêchera pas d'utiliser Firefox, mais cela a deux conséquences : D'une part la stabilité de Firefox n'est pas garantis et d'autre part les plugins ne seront pas utilisables (en tout cas, pas facilement).

Vous pouvez également utiliser les dépôts PPA pour faire l'installation (ce qui vous permettra de trouver des compilations 64 bits !)... je ne vais pas trop m'appesantir la dessus vu que je fait une allergie complète à ce système (j'y comprend rien et je n'ai pas envie d'y comprendre quoi que ce soit... je sais, c'est génial et je ne sais pas de quoi je me prive, mais ça me gonfle et je trouve ça beaucoup trop nerd pour moi)

Installer Firefox

L'installation en tant que tel est assez trivial : décompactez l'archive que vous avez téléchargée, et voila, c'est installé. Bon, ok, soyons un peu sérieux. La version de Firefox que vous avez téléchargée est effectivement directement exécutable (sous Ubuntu, vous n'avez aucune question de dépendance à gérer, c'est assez confortable mais je ne sais pas si c'est aussi simple avec d'autres distributions) mais elle est loin d'être intégré au système.

Je ne vais pas vous harasser d'une explication fastidieuse alors que tout est extrêmement bien documenté en français ici : http://doc.ubuntu-fr.org/firefox

Ça y est ? Vous avez installé une autre version de Firefox ? Vous êtes près à double-cliquer sur l'icône de lancement ? Alors là, vous arrêtez tout, vous respirez un grand coup et vous vous posez la question de votre profil utilisateur !

On ne le dira jamais assez, mais avant toute chose, sauvegardez votre profil Firefox habituel ! J'insiste, un accident malheureux est si vite arrivé.

Sous Ubuntu 9.10, tous vos profils utilisateur se trouve dans ~/.mozilla/firefox

C'est particulièrement critique si vous voulez jouer le mode aventure extrême avec les nightly de Firefox. De manière général, je vous invite à vous créer plusieurs profils dédiés à vos tests. Pour créer de nouveau profil ou pour choisir un profil spécifique, il suffit de lacer Firefox avec l'option -p. Vous pouvez rajouter cette options dans les lanceurs d'application d'Ubuntu (clique droit, "propriété") ou bien lancer Firefox depuis la ligne de commande :

firefox -p

Selon les tests que vous voulez réaliser, il peut aussi être utile de créer un profil temporaire pour la seul durée de ces tests. Pascal documente très bien la façon de faire cela sur son site.

De même, vous pouvez avoir besoin de lancer plusieurs instances de Firefox en parallèle (par exemple si vous avez une version stable pour votre navigation quotidienne et que vous voulez réaliser un test sur une version instable). Pour cela, il vous suffit de lancer Firefox avec l'option --no-remote :

firefox --no-remote

La phase de tests

Voila vous êtes près, vous pouvez commencer vos tests. Soyons bien claire, vous êtes libre de tester ce que vous voulez : Le support des standards du Web, les performances du navigateur, la qualité de l'interface utilisateur, la gestion des extensions... c'est vous qui voyez ce qui vous intéresse. Personnellement, lors des phases de beta-test publique, je me contente de surfer "comme d'habitude" et de relever les éventuels problèmes que je rencontre.

Automatisez vos tests

Quoi qu'il en soit, dans une démarche de beta-tests (ou pire, d'alpha-tests), vous risquez d'être amener à reproduire plusieurs fois les mêmes actions. En effet, que ce soit pour vous assurer qu'il n'y a pas de régression d'une version à l'autre ou bien qu'une dysfonction a été corrigée, il va vous falloir refaire plusieurs fois les mêmes actions. En soit, c'est déjà quelque chose de fastidieux, mais en plus, il peut se passer plusieurs mois entre la réalisation de vos différents tests (ça peut prendre du temps de corriger un bug) et se souvenir de ce qu'on a fait il y a plusieurs jours/semaines/mois est loin d'être évident. Il est donc vivement conseillé d'automatiser vos tests pour éviter d'avoir à vous prendre la tête avec ça. Cette phase d'automatisation peut également vous faciliter la vie lorsque vous aurez des bugs à signaler (j'y reviens plus loin).

Pour réaliser cette automatisation, vous avez le choix des armes. cela dépendra de vos connaissances techniques et de vos besoins de test. Ça peut aller de la réalisation d'une page HTML qui recouvre un certain nombre de cas de test à la réalisation d'un script bash complet. Il existe néanmoins une extensions de Firefox qui peut vous être utile : iMacros pour Firefox. Cette extension permet d'enregistrer et rejouer toutes les taches que vous pouvez faire avec Firefox (pas seulement ce que vous faite dans un page web mais vraiment tout, y compris les interactions avec l'interface utilisateur).

L'équipe Assurance Qualité de Mozilla

Si vous êtes vraiment motivé, vous pouvez également aider (pour ne pas dire rejoindre ) l'équipe d'assurance qualité de Mozilla. Elle fédère l'effort de test des produits Mozilla. Elle propose un certains nombre d'outils, organise des évènements spécifiques et met en œuvre un catalogue de cas de tests. Vous trouverez plus d'informations sur le site de Mozilla dédié à l'Assurance Qualité (en anglais).

Cette équipe propose même une extension spécifique pour vous accompagner dans vos démarches de test : le Mozilla QA Companion.

Signaler un bug

Ça y est, là vous êtes chaud. Vous utilisez votre Firefox tout nouveau tout beau, et là... Paf ! C'est le drame ! Vous êtes confronté à un bug. Comme vous êtes quelqu'un de bien, vous allez le signaler à Mozilla. Je ne vais pas vous le cacher, en général, c'est là que ça se corse. Ça se corse parce que le reporting de bug se fait exclusivement en anglais. Là, il n'y a pas vraiment le choix, l'anglais étant la langue partagée par quasiment tous les développeurs de la planète, c'est ce qui est le plus facile pour tout le monde... mais pas forcément pour vous. Détendez vous quand même, il n'y a pas besoin d'être bac+5 d'anglais. Au pire du pire, si vraiment c'est un obstacle insurmontable pour vous, vous pouvez gentiment aller en discuter avec les différentes communautés Mozilla françaises. Que ce soit les traducteurs de FrenchMozilla (D'ailleurs, si votre bug est un bug de traduction, c'est eux qu'il faut aller voir) ou les administrateurs de GeckoZone, si vous leur demandez poliment de l'aide, vous ne devriez pas être bombardé de cailloux, au contraire

Pour signaler un bug, ça se passe sur le site Bugzilla de Mozilla. Mais ne nous précipitons pas, faisons cela dans les règles de l'art (il sera bien temps de faire ça n'importe comment le moment venu ).

Vérifier si ce bug n'a pas déjà été signalé

Alors avant de s'énerver, la première chose à faire est de vérifier si le bug que vous avez repéré n'a pas déjà été signalé par quelqu'un d'autre. En effet, ce n'est pas la peine de signaler un bug qui a déjà été pris en charge par les développeurs et qui sera donc corrigé dans la prochaine version stable/beta/nightly. De même, il est plus constructif de compléter un bug existant que de faire un doublon.

Bon, ne nous le cachons pas, l'interface de bugzilla est cauchemardesque d'un point de vue ergonomique. C'est un outils fait pour les développeurs de Mozilla. Si vous êtes un contributeur occasionnel, abandonnez ici tout espoirs ! Faire une recherche de bug si vous n'avez pas l'habitude des arcanes de l'organisation des développements chez mozilla, c'est l'horreur. Alors si malgré vos effort vous ouvrez un bug qui en doublonne un autre, ne vous inquiétez pas, Mozilla dispose d'une équipe de triage des bugs qui assure grave ! Ne soyez donc pas surpris si vous voyez que votre bug est marqué comme étant un doublon, ça vous arrivera régulièrement, surtout au début

Qualifier votre bug

Maintenant que vous savez (ou croyez savoir, ou n'avez pas envie de savoir) que personne n'a déjà signalé votre bug, vous pouvez vous lancer dans votre rapport de bug. Oui, mais pas de précipitation. Avant de vous jeter sur Bugzilla, prenez le temps de préparer un rapport complet. En effet, il n'y a rien de plus inutile qu'un rapport de bug sous la forme de "Y'a tel machin qui marche pas". En effet, les personnes qui vont traiter le bug ne sont pas à votre place, il faut donc leur donner un minimum de contexte pour qu'ils puissent travailler efficacement.

Un rapport de bug exploitable contiens un certain nombre d'informations clés :

Commencez par dire quel est la version de Firefox que vous utilisez et votre système d'exploitation. Le plus simple est de coller purement et simplement la "User Agent String" de votre navigateur dans votre rapport de bug. Vous la trouverez en vous rendant dans le menu : Aide > A propos de Mozilla Firefox
Décrivez toutes les étapes qui permettent de reproduire le bug (idéalement sous forme d'une liste ordonnée). Si vous avez pensé à automatiser vos tests, vous pouvez en plus joindre le script d'automatisation, les développeurs pourront alors reproduire assez simplement le problème (et donc potentiellement traiter votre bug plus vite ). Si ce bug ne peut pas être reproduit systématiquement, précisez le bien et essayez de qualifier sa fréquence d'apparition.
Précisez le résultat normalement attendu par votre test et le résultat réel constaté de votre test. Encore une fois plus vous serez précis sur ces deux points, plus le bug sera facile à identifier et à corriger.

Ouvrir un bug

Bon, ben nous y voila, c'est le grand moment. Si ce n'est déjà fait, commencez par vous ouvrir un compte sur Bugzilla et faites l'effort de survoler le guide de bonne conduite de Bugzilla (c'est court et pas prise de tête, mais on y retrouve quelque points important pour une bonne vie en communauté). Une fois identifié, vous n'avez plus qu'à remplir votre rapport de bug et voila... vous faites désormais partis de la grande famille des contributeurs au projet Mozilla. Bravo

Conclusion

Comme vous pouvez le voir, il n'y a rien de vraiment compliqué. Il n'est même pas nécessaire que vous ayez des connaissances techniques particulières. C'est tout l'intérêt du mode de développement ouvert de Mozilla : tout le monde peu participer dans la mesure de ses moyens, connaissances, disponibilités. En fait, le seul problème que j'ai avec Mozilla, c'est la difficulté à trouver comment participer. En effet, Mozilla communique assez mal sur comment il est possible de participer. Mozilla dispose de tout un tas d'outils et il est parfois difficile de savoir ou commencer dans la profusion des possibilité qui sont offerte. En dehors du développement, il existe des tas d'autres choses à faire avec Mozilla : du marketing, de la R&D, de l'ergonomie, et bien plus. C'est parce qu'il est difficile de savoir ou commencer que j'ai écris cet article. J'essayerai de vous parler de toutes ces autre opportunités pour les non-développeur au seins du projet Mozilla car ce n'est pas toujours claire pour s'y retrouver. N'hésitez pas à vous renseigner sur les forums de discutions francophone, les gens sont sympas et n'hésiteront pas à vous aider à démarrer. Bienvenu !