Définition du chrome
Le chrome est l'ensemble des éléments de l'interface utilisateur d'une application qui sont situés en dehors de la zone de contenu d'une fenêtre. Les barres d'outils, les barres de menus, les barres de progression, et les titres de fenêtres sont tous des exemples d'éléments qui font habituellement partie du chrome.
Fournisseurs de chrome
Ce qui fournit le chrome pour un type de fenêtre donnée (par exemple pour la fenêtre du navigateur) est appelé un fournisseur de chrome (Chrome Provider). Les fournisseurs collaborent pour fournir un jeu complet de chrome pour une fenêtre particulière, depuis les images des boutons de la barre d'outils jusqu'aux fichiers décrivant le texte, le contenu et l'apparence de la fenêtre elle-même.
Il y trois types basiques de fournisseurs de chrome :
content
Le fichier principal pour la description d'une fenêtre provient du fournisseur « content », et il peut s'agir de n'importe quel type de fichier que Mozilla peut afficher. Il s'agit généralement de fichiers XUL, puisque XUL est conçu pour décrire le contenu de fenêtres et de boîtes de dialogue. Les fichiers JavaScript définissant l'interface utilisateur font également partie des paquetages content, ainsi que la plupart des fichiers de liaisons XBL.
locale
Les applications localisables (disponibles en plusieurs langues) ont leurs informations de localisation dans des fournisseurs « locale ». Cela permet aux traducteurs de fournir un paquetage différent pour traduire toute une application sans toucher au reste du code source. Les deux principaux types de fichiers de localisation sont les fichiers DTD et les fichiers properties de style Java.
skin
Un fournisseur « skin » est responsable de la fourniture complète des fichiers décrivant l'apparence visuelle du chrome. Typiquement, un thème graphique fournit des fichiers CSS et des images.
Le registre chrome
L'environnement d'exécution Gecko s'occupe d'un service appelé le registre chrome fournissant une cartographie complète permettant de lier les noms de paquetages chrome et leurs emplacements physiques sur le disque.
Le registre chrome est configurable et persistant, un utilisateur peut donc installer des fournisseurs de chrome différents et sélectionner un thème ou une langue préférée. Tout ceci est accompli au travers d'xpinstall et du gestionnaire d'extensions.
Afin d'informer le registre chrome de la présence d'un nouveau chrome, un texte de présentation appelé manifest est utilisé : il s'agit du fichier chrome.manifest à la racine d'une extension ou d'un thème, ou d'une application XULRunner.
Ces fichiers sont de simples fichiers textes présentés ligne par ligne. Chaque ligne est interprétée individuellement. Si la ligne peut être interprétée, le registre chrome réalise l'action identifiée par cette ligne, autrement, le registre chrome ignorera cette ligne (et affichera un message d'alerte dans la console d'erreurs d'exécution).
locale nomdupaquetage nomlocale chemin/vers/fichiers skin nomdupaquetage nomskin chemin/vers/fichiers
Instructions du fichier manifest
Commentaires
Une ligne est un commentaire si elle commence par le caractère « #» ; tous les autres caractères sur la ligne seront ignorés.
# cette ligne est un commentaire - vous pouvez mettre ce que vous voulez ici
content
Un paquetage de type content est enregistré par la ligne :
content nomdupaquetage uri/vers/fichiers/ [drapeaux]
Ceci va enregistrer un emplacement à utiliser lors de la résolution de l'URI chrome://nomdupaquetage/content/.... L'URI peut être absolue ou relative à l'emplacement du fichier manifeste. Notez qu'elle doit se terminer par une barre oblique « / ».
locale
Un paquetage de type locale est enregistré par la ligne :
locale nomdupaquetage nomlocale uri/vers/fichiers/ [drapeaux]
Ceci va enregistrer un paquetage locale lors de la résolution de l'URI chrome://nomdupaquetage/locale/... . La chaîne nomlocale est habituellement un identifiant de langue comme « en » ou de langue spécifique à un pays comme « en-US ». Si plus d'une localisation est enregistrée pour un paquetage, le registre chrome sélectionnera la plus appropriée en fonction des préférences de l'utilisateur.
skin
Un paquetage de thème est enregistré par la ligne :
skin nomdupaquetage nomskin uri/vers/fichiers/ [drapeaux]
Ceci va enregistrer un paquetage de thème lors de la résolution de l'URI chrome://nomdupaquetage/skin/... . La chaîne nomskin est une chaîne opaque identifiant le thème installé. Si plus d'un thème est enregistré pour un paquetage, le registre chrome sélectionnera le plus approprié en fonction des préférences de l'utilisateur.
overlay
Les overlays XUL sont enregistrés avec la syntaxe suivante :
overlay chrome://URI-ou-appliquer-overlay chrome://overlay-URI [drapeaux]
style
Les overlays de style (CSS personnalisée qui sera appliquée à une page chrome) sont enregistrés avec la syntaxe suivante :
style chrome://URI-vers-style chrome://stylesheet-URI [drapeaux]
override
Dans certains cas, une extension ou une application embarquant le moteur peut avoir envie de remplacer un fichier chrome fourni par l'application ou par XULRunner. Pour autoriser ce remplacement, le manifeste d'enregistrement chrome doit contenir des instructions « override » :
override chrome://paquetage/type/uri-originelle.qqc nouvelle-URI-résolue [drapeaux]
Note : les overrides ne sont pas récursifs (donc remplacer chrome://foo/content/bar/ par file:///home/john/blah/ ne fera généralement pas ce que vous désirez ou vous attendez à voir).
Un bogue est actuellement présent dans les versions de Gecko antérieures à 1.8.0.13 et 1.8.1.5, ainsi que dans des compilations plus anciennes, où l'utilisation d'une URL relative pour le paramètre nouvelle-URI-résolue ne fonctionnera pas. Il est nécessaire de fournir une URL complètement qualifiée (c'est-à-dire qui peut être résolue n'importe où, pas uniquement dans le répertoire dans lequel le manifeste chrome se trouve). Étant donné que le développeur d'extension ou d'application est incapable de prédire ce que sera le chemin vers un tel fichier, il est actuellement uniquement possible d'utiliser cette directive avec une autre URL chrome:// comme paramètre nouvelle-URI-résolue. Voir le bug 323455.
Drapeaux de fichiers manifest
Dans les fichiers manifest, plusieurs drapeaux séparés par des virgules peuvent être ajoutés à la fin des lignes d'enregistrement. Ces drapeaux indiquent des attributs spéciaux du chrome dans ce paquetage ou limite les conditions d'utilisation de la ligne.
application
Des extensions peuvent s'installer dans plusieurs applications différentes. Certaines lignes d'enregistrement chrome peuvent toutefois être réservées à une application particulière. Le drapeau
application=app-ID
indique que l'instruction ne doit être appliquée que si l'extension est installée dans une application ayant pour identifiant app-ID. Plusieurs drapeaux application peuvent être fournis sur une même ligne, auquel cas elle sera appliquée si n'importe lequel d'entre-eux correspond.
appversion
Des extensions peuvent s'installer dans plusieurs versions différentes d'une application. Il peut y avoir des lignes d'enregistrements chrome qui ne s'appliquent qu'à une version particulière de l'application. Le drapeau
appversion=version appversion<version appversion<=version appversion>version appversion>=version
indique que l'instruction ne doit s'appliquer que si l'extension est installée dans la version de l'application indiquée. Plusieurs drapeaux appversion peuvent figurer sur la même ligne, auquel cas la ligne sera appliquée si n'importe lequel d'entre-eux correspond. La chaîne de version doit se conformer au Format de version du toolkit.
platform (paquetages propres à la plateforme)
Certains paquetages sont marqués à l'aide d'un drapeau particulier indiquant qu'ils sont propres à une plateforme. Certaines parties de content, skin ou locale peuvent être différents selon la plateforme sur laquelle l'application est exécutée. Ces paquetages contiennent trois jeux de fichiers différents, pour Windows/OS2, Macintosh et les plateformes de type Unix. Par exemple, l'ordre des boutons « OK » et « Annuler » dans un dialogue n'est pas le même d'une plateforme à l'autre, de même que le nom de certains éléments.
L'indicateur « platform » n'est pris en compte que dans le cas d'un enregistrement content, il n'est pas reconnu dans le cas d'un enregistrement locale ou string. Cependant, il s'applique aux parties content, locale et skin lorsque spécifié.
Pour indiquer qu'un paquetage est propre à une plateforme, ajoutez l'indicateur « platform » après le chemin sur la ligne content, par exemple :
content global-platform jar:toolkit.jar!/toolkit/content/global-platform/ platform
Une fois ceci spécifié dans votre fichier manifest, assurez-vous ensuite que, sous le répertoire global-platform, les sous-répertoires win (Windows/OS2), mac (OS9/OSX), ou unix (tous les autres cas) sont présents. Tout ce qui se trouve en dehors de ces sous-répertoires sera ignoré.
xpcnativewrappers
Les paquetages chrome peuvent décider s'ils utilisent ou non le mécanisme de sécurité XPCNativeWrapper pour protéger leur code contre du contenu malveillant auquel ils pourraient eccéder. Consultez Accès sécurisé au contenu DOM depuis le chrome pour plus de détails.
Dans les versions alpha de Firefox 1.5 alpha (les alphas Deer Park), ce drapeau est *désactivé* par défaut, et doit être activé explicitement en spécifiant xpcnativewrappers=yes.
À partir de la première version beta de Firefox 1.5, ce drapeau est activé par défaut, et les extensions qui ont besoin d'accès non sécurisés aux objets du contenu devront spécifier explicitement xpcnativewrappers=no.
Le drapeau xpcnativewrappers ne s'applique qu'au paquetages de type content : il n'est pas reconnu par les enregistrements locale ou skin.
Exemple de fichier manifest chrome
content necko jar:comm.jar!/content/necko/ xpcnativewrappers=yes locale necko fr jar:fr.jar!/locale/fr/necko/ content xbl-marquee jar:comm.jar!/content/xbl-marquee/ content pipnss jar:pipnss.jar!/content/pipnss/ locale pipnss fr jar:fr.jar!/locale/fr/pipnss/ # Firefox uniquement overlay chrome://browser/content/pageInfo.xul chrome://pippki/content/PageInfoOverlay.xul application={ec8030f7-c20a-464f-9b0e-13a3a9e97384} overlay chrome://communicator/content/pref/preftree.xul chrome://pippki/content/PrefOverlay.xul overlay chrome://navigator/content/pageInfo.xul chrome://pippki/content/PageInfoOverlay.xul [email protected] content pippki jar:pippki.jar!/content/pippki/ xpcnativewrappers=yes locale pippki fr jar:fr.jar!/locale/fr/pippki/ content global-platform jar:toolkit.jar!/content/global-platform/ platform skin global classic/1.0 jar:classic.jar!/skin/classic/global/ override chrome://global/content/netError.xhtml jar:embedder.jar!/global/content/netError.xhtml content inspector jar:inspector.jar!/content/inspector/ xpcnativewrappers=no
Anciens fichiers manifest de type contents.rdf
Avant que les fichiers texte de type manifest soient mis en place (avec Firefox 1.5 et la version 1.8 du toolkit), des fichiers RDF appelés « contents.rdf » étaient utilisés pour les enregistrements chrome. Ce format n'est plus recommandé, cependant la suite Mozilla (SeaMonkey) ne permet pas encore d'utiliser les fichiers texte au format manifest, et des fichiers contents.rdf sont toujours nécessaires pour les extensions qui désirent maintenir une rétrocompatibilité avec Firefox 1.0 ou la suite.