From a065e04d529da1d847b5062a12c46d916408bf32 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 21:46:22 -0500 Subject: update based on https://github.com/mdn/yari/issues/2028 --- .../firefox/compiler_firefox_avec_rust/index.html | 38 ----- .../firefox/deploiement_entreprise/index.html | 145 ----------------- .../mozilla/firefox/developer_edition/index.html | 57 ------- .../firefox/developer_edition/reverting/index.html | 23 --- files/fr/mozilla/firefox/firefox_esr/index.html | 15 -- files/fr/mozilla/firefox/headless_mode/index.html | 124 --------------- .../mozilla/firefox/le_protocole_about/index.html | 174 --------------------- .../firefox/multiprocessus_firefox/index.html | 77 --------- .../multiprocessus_firefox/motivation/index.html | 44 ------ .../technical_overview/index.html | 164 ------------------- files/fr/mozilla/firefox/privacy/index.html | 15 -- .../protection_contre_le_pistage/index.html | 79 ---------- .../protection_du_pistage_par_rebond/index.html | 101 ------------ files/fr/mozilla/firefox/versions/14/index.html | 90 ----------- 14 files changed, 1146 deletions(-) delete mode 100644 files/fr/mozilla/firefox/compiler_firefox_avec_rust/index.html delete mode 100644 files/fr/mozilla/firefox/deploiement_entreprise/index.html delete mode 100644 files/fr/mozilla/firefox/developer_edition/index.html delete mode 100644 files/fr/mozilla/firefox/developer_edition/reverting/index.html delete mode 100644 files/fr/mozilla/firefox/firefox_esr/index.html delete mode 100644 files/fr/mozilla/firefox/headless_mode/index.html delete mode 100644 files/fr/mozilla/firefox/le_protocole_about/index.html delete mode 100644 files/fr/mozilla/firefox/multiprocessus_firefox/index.html delete mode 100644 files/fr/mozilla/firefox/multiprocessus_firefox/motivation/index.html delete mode 100644 files/fr/mozilla/firefox/multiprocessus_firefox/technical_overview/index.html delete mode 100644 files/fr/mozilla/firefox/privacy/index.html delete mode 100644 files/fr/mozilla/firefox/privacy/protection_contre_le_pistage/index.html delete mode 100644 files/fr/mozilla/firefox/privacy/protection_du_pistage_par_rebond/index.html delete mode 100644 files/fr/mozilla/firefox/versions/14/index.html (limited to 'files/fr/mozilla/firefox') diff --git a/files/fr/mozilla/firefox/compiler_firefox_avec_rust/index.html b/files/fr/mozilla/firefox/compiler_firefox_avec_rust/index.html deleted file mode 100644 index b44152a57f..0000000000 --- a/files/fr/mozilla/firefox/compiler_firefox_avec_rust/index.html +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: Compiler Firefox avec Rust -slug: Mozilla/Firefox/Compiler_Firefox_avec_Rust -tags: - - Compilation - - Gecko - - rust -translation_of: Archive/Mozilla/Firefox/Building_Firefox_with_Rust_code ---- -

En mai 2015 le langage de programmation Rust a atteint sa version stable 1.0 et diverses expérimentations comme la rédaction de parties de Gecko en Rust ont commencé. Cette page est un guide sommaire destiné aux personnes travaillant sur ce projet.

- -

Ajouter le code Rust

- -

Le support de base pour la compilation avec le code Rust est disponible sur la page du bogue 1161339. Si vous disposez de rustc dans votre variable path vous pouvez ajouter les fichiers .rs à la variable SOURCES dans moz.build, puis ajouter :

- -

ac_add_options --enable-rust

- -

à votre mozconfig et ça devrait fonctionner.

- -

La bibliothèque standard de rust utilise un thread local de stockage qui n'est pas supporté sur MacOS X 10.6. Ainsi, si vous compilez le projet depuis un Mac vous devez aussi ajouter :

- -

ac_add_options --enable-macos-target=10.7

- -

Vous pouvez aussi compiler une toolchain personnalisée de Rust sans la partie relative à std::thread. Pour plus de détails, regardez le bogue 1164109.

- -

Because of limitations of cargo and the Firefox build system, currently we build a stand-alone static lib from each rust file listed in SOURCES. You must therefore list just the top-level rust file. Everything must be a single crate, like a manual unified build. The rust compiler will search for interior modules by source file name, but extern crate references won't be resolved.

- -

Allez voir le bogue 1135640 ('oxidation') pour un suivi global.

- -

Tester le code Rust

- -

Il existe un test unitaire simple de disponible dans le répertoire du projet. Vous pouvez l'utiliser pour savoir si Rust est activé et fonctionne avec votre configuration.

- -

./mach gtest rust.*

- -

Regardez si le test rust.CallFromCpp réussi ainsi que tous les autres.

diff --git a/files/fr/mozilla/firefox/deploiement_entreprise/index.html b/files/fr/mozilla/firefox/deploiement_entreprise/index.html deleted file mode 100644 index 13913c8e06..0000000000 --- a/files/fr/mozilla/firefox/deploiement_entreprise/index.html +++ /dev/null @@ -1,145 +0,0 @@ ---- -title: Déploiement de Firefox dans un environnement d'entreprise -slug: Mozilla/Firefox/deploiement_Entreprise -tags: - - Déploiement - - Entreprise - - Firefox -translation_of: Mozilla/Firefox/Enterprise_deployment_before_60 ---- -

- -

Cette page documente de pied en cap le processus de gestion de Mozilla Firefox sur des ordinateurs fonctionnant sur Windows ou macOS dans le cadre d'une entreprise. Vous pouvez envoyer vos questions par courrier électronique à la liste de diffusion du groupe de travail pour les entreprises (Enterprise Working Group) via enterprise@mozilla.org (en anglais). Mieux encore, vous pouvez rejoindre les discussions en cours en vous inscrivant à la liste en anglais ou en français.

- -

Note : cet article couvre des versions de Firefox antérieures à Firefox 60 ESR. Pour un déploiement dans des environements d’enterprises dans Firefox 60 ou plus récent, consultez l’article Deploying Firefox in an enterprise environment.

- -

Choisissez une variante de Firefox

- -

RR (Version Rapide)

- -

Mozilla publie une nouvelle version majeure avec de nouvelles fonctionnalités et des corrections de bugs toutes les six semaines (et, si besoin, des mises à jour de sécurité durant cette période). Le jour où une version majeure est lancée, dans la plupart des cas (voir plus bas pour les exceptions), Mozilla arrête de fournir des correctifs de bugs pour les versions précédentes.

- -

Pour vous renseigner sur les dates de sortie des prochaines versions, vous pouvez regarder ce tableau sur le wiki Mozilla.

- -

ESR (version de support étendu)

- -

Chaque septième version majeure de Firefox est déclarée version de support étendu. Ces versions reçoivent les corrections des gros bugs issus des versions mineures pendant 54 semaines (neuf cycles de six semaines). De plus, un chevauchement de 12 semaines (deux cycles de six semaines) entre deux versions successives de type ESR est effectué, au cours de laquelle les deux versions ESR obtiennent des corrections de bugs.

- -

Les versions ESR sont les versions 10, 17, 24, 31 et 38.

- -

De nombreuses entreprises et organisations avec des environnements informatiques généralisés préfèrent utiliser des versions ESR que des versions RR car elles peuvent tester leur comptabilité sur une période de 42 semaines au lieu de la période de 6 semaines (entre chaque RR). De plus si elles ont un problème, elles disposent de 12 semaines de plus (chevauchement entre 2 versions ESR) pour trouver une solution (en plus des 6 semaines obtenues en testant la version beta).

- -

Notez que des effets indésirables peuvent se faire ressentir si vous passez d'une version RR à une version ESR antérieure. En effet, les versions RR voient parfois de nouvelles fonctionnalités non finies intégrées à leur code pour pouvoir les tester, mais désactivées par les préférences. Lors d'un retour à une version précédente, les utilisateurs gardent leurs derniers paramètres dans leur répertoire de profil. Une option peut alors être activée sans qu'elle ne soit totalement fonctionnelle sur la version ESR. Si vous souhaitez passer d'une version RR à une version ESR, vous devriez le faire lorsqu'une nouvelle version ESR voit le jour.

- -

Installation

- -

Téléchargez la dernière version de Firefox depuis https://www.mozilla.org/en-US/firefox/all/ (RR) ou https://www.mozilla.org/en-US/firefox/organizations/all/ (ESR).
Installez la version sur le système d'exploitation de votre choix (L'option pour une installation silencieuse est -ms).
Vous pouvez aussi créer un fichier d'initialisation. Pour plus d'informations, vous pouvez visiter cette page (en).

- -

Configuration

- -

Trouvez le répertoire où l'exécutable est présent. Par exemple, sur Windows 7 (64 bits), le répertoire est souvent C:\Program Files (x86)\Mozilla Firefox; dans Mac OSX 10.8 il s'agit de /Applications/Firefox.app/Contents/MacOS. Les sous-répertoires mentionnés par la suite sont relatifs à ce dossier.
Créez un fichier javascript dans defaults/pref (généralement, autoconfig.js - d'autres noms fonctionnent, mais pour de meilleurs résultats, il faut que le nom commence par un 'a'). Le contenu de ce fichier indique à Firefox où trouver le fichier de configuration. (Pour plus d'informations : Customizing Firefox default preference files (en)).Les trois lignes dont vous avez besoin sont : -
```
// Vous devez démarrer ce fichier avec un commentaire !
-pref("general.config.filename", "mozilla.cfg");
-pref("general.config.obscure_value", 0);
```
-
Créez un fichier .cfg (généralement mozilla.cfg — le nom peut être différent, mais il faut que ça corresponde au nom entré dans les 2 lignes précédentes) dans le répertoire du programme. Passez ou commentez la première ligne, puis commencer à mettre vos préférences. Pour savoir quelles préférences mettre, rendez-vous sur la page about:config sur une copie de Firefox correctement configurée et regardez les préférences ayant pour statut "user set", ou regardez les exemples suivants. Toute préférence peut être réglée via une des fonctions suivantes : -
-
pref
-
Un utilisateur peut changer une valeur, mais elle sera effacée au prochain redémarrage. Si vous mettez une préférence de cette manière, elle sera montrée comme "user set" dans about:config
-
defaultPref
-
pour modifier la valeur par défaut. Si un utilisateur change cette valeur, il pourra la garder entre plusieurs sessions. Les préférences peuvent être réinitialisées via la GUI ou autre méthode. Elle sera montrée avec un statut "default" dans about:config
-
lockPref
-
pour bloquer les préférences. Elles ne pourront pas être changées par la GUI ou via about:config. Dans la majeure partie des cas, la GUI va enlever l'option ou la griser. Certains éléments de la configuration nécessitent un réglage via lockPref, tels que app.update.enabled (pref ne fonctionnera pas).
-
clearPref
-
pour rendre vierge certaines préférences. Peut s'avérer utile pour désactiver des fonctions se basant sur un numéro de version.
-
-

- -

Vous pouvez visiter Customizing Firefox autoconfig files (en) ou Customizing Firefox autoconfig files continued (en) pour plus d'informations. Pour désactiver des éléments de l'interface utilisateur, vous pouvez utiliser l'extension CCK2.

- -

Exemple de fichier de configuration

- -

Dans l'exemple qui suit, vous pouvez voir des exemples de références nécessitant l'utilisation de lockPref.

- -

// Désactive la mise à jour automatique
-lockPref("app.update.enabled", false);
-// pour être sûr que la mise à jour automatique soit désactivée
-lockPref("app.update.auto", false);
-lockPref("app.update.mode", 0);
-lockPref("app.update.service.enabled", false);
-
-// Désactive la vérification de la comptabilité des extensions
-clearPref("extensions.lastAppVersion");
-
-// Désactive l'affichage de 'Connaître vos droits' au premier lancement
-pref("browser.rights.3.shown", true);
-
-// Ne montre pas les nouvelles fonctionnalités à chaque mise à jour
-pref("browser.startup.homepage_override.mstone","ignore");
-
-// Modifie la page d'accueil
-defaultPref("browser.startup.homepage", "http://home.example.com");
-
-// Désactive le lecteur de pdf interne
-pref("pdfjs.disabled", true);
-
-// Désactive le convertisseur flash vers javascript
-pref("shumway.disabled", true);
-
-// Ne demande pas d'installer le plugin flash
-pref("plugins.notifyMissingFlash", false);
-
-// Désactive la vérification des plugins
-lockPref("plugins.hide_infobar_for_outdated_plugin", true);
-clearPref("plugins.update.url");
-
-// Désactive le rapport de santé
-lockPref("datareporting.healthreport.service.enabled", false);
-
-// Disable all data upload (Telemetry and FHR)
-lockPref("datareporting.policy.dataSubmissionEnabled", false);
-
-// Désactive le rapport de crashs
-lockPref("toolkit.crashreporter.enabled", false);
-Components.classes["@mozilla.org/toolkit/crash-reporter;1"].getService(Components.interfaces.nsICrashReporter).submitReports = false; 
-

- -

Packaging d'extensions

- -

Installez l'extension sur une machine de test. Regardez la page about:support sous Extensions pour trouver le GUID
Regardez dans le répertoire des profils (ex: %APPDATA%\Mozilla\Firefox\Profiles pour Win7; pour le trouver, regardez Profile Directory sur la page about:support), puis sous "Extensions" pour l'extension souhaitée. Il s'agit soit d'un fichier .xpi (correspondant à un .zip) ou un dossier avec de multiples fichiers.
Décidez de la façon dont vous voulez la déployer. La méthode la plus simple est de copier le .xpi ou le dossier dans le dossier /distribution/extensions mais cette méthode ne fonctionne que pour les profils créés après l'ajout de l'extension. De plus, si vous réinstallez firefox, le dossier sera supprimé, assurez-vous de réinstaller les extensions par la suite. Vous pouvez vous rendre sur cette page Integrating add-ons into Firefox (en) pour trouver d'autres méthodes.

- -

Changements au fil du temps

- -

Changement dans la structure des répertoires

- -

La structure des répertoires intégrée au programme a changé 2 fois. Si vous lisez des descriptions sorties avant la version 21, il faut probablement prendre en compte les points suivants :

- -

Dans la version 14, certains paramètres ont arrêté de fonctionner lorsqu'ils étaient dans un fichier du répertoire defaults/pref. La solution pour régler le problème était de créer un répertoire directory defaults/preferences et de les mettrent ici.
Dans la version 21, le nouveau dossier appelé browser fut créé. Le fichier override.ini et les dossiers defaults/preferences, defaults/profile, extensions, plugins, and searchplugins furent déplacés ici. Les plugins du répertoire plugins peuvent être réactivés en modifiant la préférence plugins.load_appdir_plugins à true.

- -

La configuration des préférences general.config.filename et general.config.obscure_value pour AutoConfiguration peut être réalisée dans le dossier defaults/pref, mais le fichier de configuration doit commencer par la lettre 'a', comme par exemple autoconfig.js.

- -

Si l'opération venait à échouer depuis defaults/pref dans une des versions suivantes de Firefox, essayez avec browser/defaults/preferences.

- -

Changement de répertoire sur Mac

- -

En raison de l'approche d'Apple plus stricte en matière de signature de logiciel, depuis environ la version 35 les fichiers de configuration doivent être placés sous /Applications/Firefox.app/Contents/Resources (c'est là que doit aller mozilla.cfg et autoconfig.js sous /Applications/Firefox.app/Contents/Resources/defaults/pref).

- -

Changements dans ESR 24.x avec les fichiers PDF Adobe

- -

Firefox RR 19.x modifie l'outil de visionnage d'Adobe pour les fichiers .pdf afin d'utiliser l'outil interne. Ce changement est présent dans la version ESR 24.x et la préférence se modifie automatiquement lors de la mise à jour depuis ESR 17.x même si un outil de visionnage externe a été configuré. Le nom du type de fichier a aussi été modifié passant de Adobe Acrobat Document à Portable Document Format (PDF), le rendant difficile à localier via les outils ou options. Pour désactiver cette fonctionnalité, modifiez pdfjs.disabled à true, comme dans le fichier d'exemple plus haut.

diff --git a/files/fr/mozilla/firefox/developer_edition/index.html b/files/fr/mozilla/firefox/developer_edition/index.html deleted file mode 100644 index 23cf232d3b..0000000000 --- a/files/fr/mozilla/firefox/developer_edition/index.html +++ /dev/null @@ -1,57 +0,0 @@ ---- -title: Édition pour les développeurs -slug: Mozilla/Firefox/Developer_Edition -tags: - - Developer Edition -translation_of: Mozilla/Firefox/Developer_Edition ---- -

- -

Une version de Firefox adaptée sur mesure pour les développpeurs web.

- -

Télécharger Firefox Developer Edition

- -

Les dernières fonctionnalités de Firefox

- -

L'édition de Firefox pour les développeurs remplace le canal de distribution Aurora dans le système de release de Firefox. De la même manière que pour Aurora, les nouvelles fonctionnalités seront intégrées à cette édition toutes les six semaines, une fois qu'elles auront été suffisamment stabilisées avec les versions Nightly.

- -

En utilisant l'édition développeur, vous pourrez avoir accès aux outils et aux fonctionnalités 12 semaines avant que ceux-ci ne soient disponibles sur le canal de release.

- -

Découvrez les nouveautés de l'édition de Firefox pour les développeurs.

- -

Des outils de développement expérimentaux

- -

Certains outils expérimentaux seront intégrés pour maturer avant d'atteindre le canal de distribution release.

- -

Ainsi, l'édition développeur intègre l'extension Valence, qui permet de connecter les outils de développement Firefox à d'autres navigateurs tels que Chrome pour Android ou Safari pour iOS.

- -

Un profil à part entière

- -

L'édition de Firefox pour les développeurs utilise un profil séparé de celui des autres versions de Firefox installées sur le même ordinateur. Cela signifie que vous pouvez facilement utiliser une version développeur en même temps qu'une version beta.

- -

Une version paramétrée pour les développeurs web

- -

Les préférences utiles au développement web sont activées et paramétrées. Le débogage du chrome et le débogage à distance sont par exemple activés par défaut.

- -

Un thème distinct

- -

Ce thème permet d'accéder plus rapidement aux outils de développement.

- -

diff --git a/files/fr/mozilla/firefox/developer_edition/reverting/index.html b/files/fr/mozilla/firefox/developer_edition/reverting/index.html deleted file mode 100644 index 231da0448a..0000000000 --- a/files/fr/mozilla/firefox/developer_edition/reverting/index.html +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: Supprimer les fonctionnalités spéciales -slug: Mozilla/Firefox/Developer_Edition/Reverting -translation_of: Mozilla/Firefox/Developer_Edition/Reverting ---- -

Changer le thème de la Developer Edition

- -

Si vous souhaitez utiliser la Developer Edition, mais que vous préférez utiliser le thème Australis utilisé dans Firefox et Firefox Beta, vous pouvez utiliser le thème normal de Firefox. Ouvrez le panneau « Personnaliser » et cliquez sur le bouton « Utiliser le thème Firefox Developer Edition ».

- -

Vous pouvez également tapper “about:addons” dans la barre d'URL, sélectionner « Apparence » et changer le thème depuis cet endroit.

- -

Revenir à Firefox Aurora

- -

Si vous souhaitez toutes les fonctionnalités pre-Beta dans Firefox Developer Edition, mais que vous ne souhaitez aucun autre changement, vous pouvez revenir à l'ancien Firefox Aurora. Cette opération restaurera votre profil et vos données de session d'avant la mise à jour. C'est un processus en deux étapes, qu'il faut suivre dans cet ordre :

- -

Ouvrez la page Préférences de la Developer Edition, et décochez la case "Autoriser Firefox Developer Edition et Firefox à s'exécuter en parallèle". Il vous sera demandé de redémarrer le navigateur.
Après avoir redémarré, vous pouvez restaurer le thème de la Developer Edition en suivant les instructions de la section « Changer le thème de la Developper Edition » ci-dessus.

- -

diff --git a/files/fr/mozilla/firefox/firefox_esr/index.html b/files/fr/mozilla/firefox/firefox_esr/index.html deleted file mode 100644 index 594d9bbaa4..0000000000 --- a/files/fr/mozilla/firefox/firefox_esr/index.html +++ /dev/null @@ -1,15 +0,0 @@ ---- -title: Firefox ESR -slug: Mozilla/Firefox/Firefox_ESR -tags: - - ESR - - Firefox pour Bureau - - LTS - - Stratégie de Groupe - - Version au Support Allongé - - gpo -translation_of: Mozilla/Firefox/Firefox_ESR ---- -

Firefox Extended Support Release (ESR) est basé sur une version officielle de Firefox pour ordinateur, le public visé étant les entreprises qui ont besoin d'un support étendu dans le cadre de déploiements d'envergure. Contrairement aux autres canaux de distribution, les versions ESR ne sont pas mises à jour toutes les six semaines avec de nouvelles fonctionnalités ; par contre, elles sont supportées pendant environ un an et reçoivent des correctifs en cas de problème de stabilité ou de risque de sécurité majeur. La version ESR actuelle se base sur Firefox 60 paru le 9 mai 2018.

- -

Nous encourageons fortement les utilisateurs de Firefox ESR à s'inscrire sur la liste de diffusion Enterprise Working Group (EWG).

diff --git a/files/fr/mozilla/firefox/headless_mode/index.html b/files/fr/mozilla/firefox/headless_mode/index.html deleted file mode 100644 index e852a2c775..0000000000 --- a/files/fr/mozilla/firefox/headless_mode/index.html +++ /dev/null @@ -1,124 +0,0 @@ ---- -title: Le mode headless -slug: Mozilla/Firefox/Headless_mode -tags: - - Automatisation - - Firefox - - Mode Headless - - QA - - node.js - - test -translation_of: Mozilla/Firefox/Headless_mode ---- -

Le mode « headless » permet d'utiliser Firefox mais sans afficher les éléments d'interface. Ça ne présente pas d'intérêt pour surfer sur le Web, mais cela permet de réaliser des tests automatisés. Cet article fournit les informations pertinentes pour pouvoir utiliser le mode headless de Firefox.

- -

Utiliser le mode headless

- -

Vous pouvez démarrer Firefox dans son mode headless grâce à une ligne de commande incluant le drapeau (flaTg) -headless. Par exemple :

- -

/chemin/vers/firefox -headless

- -

Pour le moment, nous n'avons pas inclus davantage d'options, mais plus seront ajoutées plus tard.

- -

Par exemple, nous travaillons à implémenter une option --screenshot, qui permettra de faire des captures d'écran depuis le mode headless de Firefox. Voir {{bug(1378010)}} pour suivre l'avancée.

- -

Prise en charge

- -

Le mode headless de Firefox fonctionne à partir de la version 55 sur Linux et à partir de la version 56+ sur Windows et Mac.

- -

Tests industrialisés à l'aide du mode headless

- -

La façon la plus utile d'utiliser ce mode headless est de faire tourner des tests industrialisés dans Firefox. Cela signifie que vous pouvez rendre votre processus de test bien plus efficace grâce à ce mode.

- -

Selenium

- -

Pour fournir un exemple d'utilisation du mode headless pour test industrialisés, nous allons créer un test recourant à Selenium via Node.js et selenium-webdriver. Pour cela, nous supposons que vous êtes déjà à l'aise avec les bases de Selenium, Webdriver et Node, puis que vous avez préparé un environnement de test. Si vous ne l'avez pas fait, rendez-vous sur le guide développant la mise en place d'un environnement de test, puis revenez lire cette documentation.

- -

Tout d'abord, soyez sûr d'avoir installé Node ainsi que selenium-webdriver sur votre machine. Ensuite, créez un nouveau fichier nommé selenium-test.js.

- -

Note : Vous pouvez également cloner ce dépôt : headless-examples qui contient un fichier de package. Il suffit donc de lancer npm install afin d'installer les dépendances nécessaires.

- -

-
Ajouter quelques lignes de code. À l'intérieur de ce fichier, commencez en important le module principal selenium-webdriver, ainsi que le sous-module firefox :
- -
```
var webdriver = require('selenium-webdriver'),
-    By = webdriver.By,
-    until = webdriver.until;
-
-var firefox = require('selenium-webdriver/firefox');
```
-
-
Puis, créez un objet binary qui représente Firefox Nightly et ajouter l'argument -headless afin qu'il puisse être lancé avec ce mode :
- -
```
var binary = new firefox.Binary(firefox.Channel.NIGHTLY);
-binary.addArguments("-headless");
```
-
-
Maintenant, créez une nouvelle instance de driver utilisant Firefox et utilisez setFirefoxOptions() afin d'inclure une option qui spécifiera que le test devra tourner sur le Nightly channel de Firefox (cette étape n'est pas nécessaire sur Linux, mais reste utile pour utiliser les fonctions avancées de la version Nightly de Firefox sur Windows/Mac tant que celle-ci n'est pas disponible en release) :
- -
```
var driver = new webdriver.Builder()
-    .forBrowser('firefox')
-    .setFirefoxOptions(new firefox.Options().setBinary(binary))
-    .build();
```
-

Il faut maintenant ajouter la ligne de code qui initiera la navigation sur la page de recherche Google :

- -

driver.get('https://www.google.com');
-driver.findElement(By.name('q')).sendKeys('webdriver');
-
-driver.sleep(1000).then(function() {
-  driver.findElement(By.name('q')).sendKeys(webdriver.Key.TAB);
-});
-
-driver.findElement(By.name('btnK')).click();
-
-driver.sleep(2000).then(function() {
-  driver.getTitle().then(function(title) {
-    if(title === 'webdriver - Google Search') {
-      console.log('Test passed');
-    } else {
-      console.log('Test failed');
-    }
-  });
-});
-
-driver.quit();

-
Enfin, démarrez le test en utilisant la commande suivante :
- -
```
node selenium-test
```
-

- -

Et c'est tout ! Après quelques secondes, vous devriez voir apparaître le message "Test passed" sur la console

- -

L'article Headless Firefox in Node.js with selenium-webdriver de Myk Melez continent d'autres conseils utiles pour créer un test industrialisé via Node.js et Selenium dans le mode headless.

- -

D'autres solutions de test

- -

Slimerjs supporte Firefox sur Linux et bientôt sur Mac et Windows. Voir l'article Headless SlimerJS with Firefox de Brendan Dahl pour plus détails.

- -

De plus, vous pourrez utiliser le mode headless de Firefox pour faire tourner des tests industrialisés développés dans la plupart des autres applications de tests, pour autant qu'elles permettent de définir une variable d'environnement.

- -

Dépannage et aide supplémentaire

- -

Si vous avez le moindre problème en utilisant le mode headless, ne vous inquiétez pas, nous sommes ici pour vous aider. Cette section a pour but de référencer toutes vos questions et les réponses que nous leur apportons.

- -

Sur Linux, certaines bibliothèques sont nécessaires pour faire tourner le mode headless de Firefox, même si ce dernier ne les utilise pas directement. Voir le {{bug(1372998)}} pour suivre la résolution du problème.

- -

Si vous souhaitez poser une question à nos ingénieurs, le meilleur moyen est de se rendre sur le canal IRC #headless de Mozilla. Si vous êtes certain d'avoir trouvé un bug, documentez le sur la plateforme Mozilla Bugzilla.

- -

Voir aussi

- -

Using Selenium with Headless Firefox (on Windows) (en anglais) par Andre Perunicic (utilise Python)
Headless Firefox in Node.js with selenium-webdriver (en anglais) par Myk Melez
Headless SlimerJS with Firefox (en anglais) par Brendan Dahl

diff --git a/files/fr/mozilla/firefox/le_protocole_about/index.html b/files/fr/mozilla/firefox/le_protocole_about/index.html deleted file mode 100644 index 0e6912b8a7..0000000000 --- a/files/fr/mozilla/firefox/le_protocole_about/index.html +++ /dev/null @@ -1,174 +0,0 @@ ---- -title: Firefox et le protocole "about" -slug: Mozilla/Firefox/Le_protocole_about -tags: - - Firefox - - Guide - - Mozilla - - Protocoles -translation_of: Mozilla/Firefox/The_about_protocol ---- -

- -

Il existe un grand nombre d'informations utiles à propos de Firefox cachées derrière le protocole d'URL about:. La plus utile est l'URL about:config qui affiche les préférences et les paramètres qui peuvent être consultés et modifiés. Voici la liste complète des URL du pseudo-protocole about: :

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Page `about:`	Description
`about:about`	Fournit un aperçu de toutes les pages about:
`about:addons`	Gestionnaire de modules complémentaires
`about:buildconfig`	Affiche la plate-forme et la configuration utilisées pour construire Firefox
`about:cache`	Affiche les informations sur les caches mémoire, disque et appcache
`about:checkerboard`	Permet de diagnostiquer les apparitions de damiers à l'affichage
`about:config`	Fournit un moyen d'inspecter et modifier les préférences et paramètres de Firefox
`about:crashes`	Liste tous les plantages qui se sont produits pendant le fonctionnement de Firefox (dans le cas où l'utilisateur a activé les rapports de plantage)
`about:credits`	Liste tous les contributeurs du projet Firefox
`about:debugging`	Affiche la page de déboguage des modules complémentaires
`about:devtools`	Introduction aux outils de développement
`about:downloads`	Affiche tous les téléchargements faits dans Firefox
`about:home`	Page de démarrage de Firefox lors de l'ouverture d'une nouvelle fenêtre
`about:license`	Affiche les informations de licence
`about:logo`	Logo de Firefox
about:memory	Fournit un moyen d'afficher l'utilisation de la mémoire, de l'enregistrer dans un rapport et de lancer les GC et CC
`about:mozilla`	Page spéciale affichant un message extrait de l'ouvrage "Le Livre de Mozilla"
`about:networking`	Affiche des informations sur le réseau
`about:newtab`	Page de démarrage à l'ouverture d'un nouvel onglet
`about:performance`	Affiche une indication de l'utilisation du processeur et de la mémoire des onglets/modules/processus
`about:plugins`	Affiche les informations sur les plugins installés
`about:policies`	Liste les stratégies d'entreprise
`about:preferences`	Paramètres de Firefox (également accessibles à partir du menu Firefox > Préférences)
`about:privatebrowsing`	Page de démarrage lors de l'ouverture d'une fenêtre de navigation privée
`about:profiles`	Affichages et gestion des profils
`about:restartrequired`	Page informant l'utilisateur de la nécessité d'un redémarage après une mise à jour
`about:reader`	Indique qu'une page utilise le mode lecture
`about:rights`	Affiche des informations sur les droits
`about:robots`	Page spéciale affichant des remarques concernant les robots
`about:serviceworkers`	Affiche les ServiceWorkers inscrits
`about:sessionrestore`	Restauration de session (affichée après un plantage de Firefox)
`about:support`	Informations de dépannage (également accessible à partir du menu Firefox > ? (point d'interrogation) > Informations de dépannage)
`about:sync-log`	Affiche un protocole de synchronisation relatif à la fonctionnalité Sync
`about:telemetry`	Affiche les données de télémétrie collectées et envoyées à Mozilla lorsque Firefox est en cours d'exécution (dans le cas où l'utilisateur a activé la télémétrie)
`about:url-classifier`	Affiche le statut de la classification d'URL (utilisée pour les protections contre l'hameçonnage et les logiciels malveillants)
`about:webrtc`	Informations sur l'utilisation de WebRTC
`about:welcome`	Page affiché après l'installation de Firefox
`about:welcomeback`	Page d'information affichée après la réinitialisation de Firefox

- -

Ces URL sont définies dans {{source("docshell/base/nsAboutRedirector.cpp")}}, à l'intérieur du tableau kRedirMap. Celui-ci couvre la plupart des URL, de config jusqu'aux URL du pseudo-protocole chrome:, comme chrome://global/content/config.xul. Les informations sur les emplacements about sont dupliquées dans {{source("docshell/build/nsDocShellModule.cpp")}}.

diff --git a/files/fr/mozilla/firefox/multiprocessus_firefox/index.html b/files/fr/mozilla/firefox/multiprocessus_firefox/index.html deleted file mode 100644 index 9a09652da6..0000000000 --- a/files/fr/mozilla/firefox/multiprocessus_firefox/index.html +++ /dev/null @@ -1,77 +0,0 @@ ---- -title: Firefox multiprocessus -slug: Mozilla/Firefox/Multiprocessus_Firefox -tags: - - multiprocessus -translation_of: Mozilla/Firefox/Multiprocess_Firefox ---- -

Dans les anciennes versions de Firefox pour bureau, le navigateur ne s'exécutait que dans un seul processus du système d'exploitation. En particulier, le JavaScript qui exécutait l'interface du navigateur (également connu sous le nom « code chrome ») s'exécutait habituellement dans le même processus que celui présent dans les pages web (appelé aussi « contenu » ou « contenu web »).

- -

Les dernières versions de Firefox exécutent l'interface du navigateur dans un processus différent de celui des pages web. Dans la première itération de cette architecture, tous les onglets tournent dans le même processus et l'interface du navigateur dans un processus différent. Dans les itérations suivantes, nous espérons avoir plus d'un processus pour le contenu. Le projet qui consiste à apporter le multiprocessus dans Firefox est appelé Electrolysis, qui correspond à l'abréviation e10s.

- -

Les pages web classiques ne sont pas affectées par l'apparition du multiprocessus dans Firefox. Les développeurs travaillant sur Firefox lui-même ou les extensions du navigateur seront affectés si leur code repose sur la possibilité d'accéder directement à du contenu web.

- -

Au lieu d'accéder au contenu directement, le JavaScript présent dans le code chrome devra utiliser le gestionnaire de messages pour accéder au contenu. Pour faciliter la transition, nous avons mis en place des objets (les Cross Process Object Wrappers) et vous pouvez vous référer à cette page pour découvrir les limitations des scripts chrome. Si vous développez des extensions, vous pouvez lire le guide pour travailler avec Firefox multiprocessus.

- -

Présentation technique: Une vision très haut niveau de comment le multiprocessus pour Firefox est mis en œuvre.
Guide de compatibilité du contenu web: Conseils et détails sur de potentiels problèmes de compatibilité des sites web qui peuvent arriver à cause de la transition. Remarque : il n'y en a pas beaucoup !
Glossaire: La définition du jargon utilisé dans le projet Electrolysis.
Gestionnaire de messages: Guide complet sur les objets utilisés pour communiquer entre le code chrome et le contenu.
Extensions basées sur le SDK: Comment migrer vos extensions en utilisant le SDK d'extensions.
Quelle URI se charge où: Un guide rapide sur quelles URI - chrome:, about:, file:, resource: - sont chargés dans chaque processus.

- -

Motivation: Pourquoi nous implémentons le multiprocessus dans Firefox : performance, sécurité et stabilité.
Guide de migration des extensions: Si vous êtes un développeur d'extension, apprenez si votre extension est affectée et comment mettre à jour votre code.
Objets CPOW: Les objets appelés Cross Process Object Wrappers sont une aide à la migration, permettant au code chrome d'accéder de manière synchrone au contenu.
Deboggage des processus du contenu: Comment déboguer du code fonctionnant dans le processus contenu.
Sélection d'onglet dans Firefox multiprocessus: Comment le passage entre les onglets marche dans Firefox multiprocessus.

- -

Limitations des scripts chrome: Les pratiques ne fonctionnant plus dans le code chrome et comment y remédier.

- -

Limitations des scripts avec privilèges: Les pratiques ne fonctionnant plus dans le code des scripts de cadre et comment y remédier.

- -

Contactez-nous

- -

Pour plus d'informations sur le projet, vous impliquer ou poser des questions :

- -

Page du projet Electrolysis: https://wiki.mozilla.org/Electrolysis
IRC: #e10s sur irc.mozilla.org
Mailing list: dev.tech.electrolysis

diff --git a/files/fr/mozilla/firefox/multiprocessus_firefox/motivation/index.html b/files/fr/mozilla/firefox/multiprocessus_firefox/motivation/index.html deleted file mode 100644 index ed2b4828b4..0000000000 --- a/files/fr/mozilla/firefox/multiprocessus_firefox/motivation/index.html +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: Motivation -slug: Mozilla/Firefox/Multiprocessus_Firefox/Motivation -translation_of: Mozilla/Firefox/Multiprocess_Firefox/Motivation ---- -

Il y a trois raisons qui nous poussent à faire tourner le contenu de Firefox dans un processus séparé : performance, sécurité, stabilité.

- -

Performance

- -

La plupart des travaux de Mozilla ces deux dernières années ont mis l'accent sur la réactivité du navigateur. Le but est de réduire les lenteurs de l'interface (jank) - c'est-à-dire quand le navigateur a l'air de se figer lors du chargement d'une grosse page, au remplissage d'un formulaire ou lors du défilement de la page. La réactivité devient plus importante que le débit sur le web aujourd'hui. Un gros du travail a été réalisé comme une partie du projet Snappy. En voici les principaux axes :

- -

Mettre les actions longues à réaliser dans un thread séparé pour que le thread principal puisse continuer à répondre.
Rendre les Entrées/Sorties asynchrones ou dans des threads séparés pour que le thread principal ne soit pas bloqué par le disque dur.
Réduire les gros codes en plusieurs petits morceaux et en exécutant la boucle d'évènement entre ces morceaux.

- -

Une grande partie de ces travaux a déjà été réalisée. Les points restants sont difficiles à résoudre. Par exemple, l'exécution de JavaScript se déroule dans le thread principal ce qui bloque la boucle d'évènements. Exécuter ces composants dans un thread séparé est difficile parce qu'ils accèdent à des données comme le DOM qui ne sont pas sécurisées dans le cas d'accès par différents threads. Comme alternative, nous avons envisagé de pouvoir exécuter la boucle d'évènements au milieu de l'exécution de JavaScript, mais cela briserait beaucoup d'hypothèses de différentes parties de Firefox (comme les extensions).

- -

Exécuter le contenu web dans un processus séparé est une alternative viable. Comme l'approche avec différents threads, Firefox est capable d'exécuter la boucle d'évènements pendant que le JavaScript et l'agencement s'exécutent dans un processus contenu. Mais, le code d'Interface Utilisateur n'a pas accès au contenu du DOM ou d'autres structures de données du contenu, il y a donc un besoin de verrouillage et de protection d'accès sur cette partie. L'inconvénient est que tout code présent dans le processus interface utilisateur de Firefox qui a besoin d'accéder au contenu doit le faire explicitement via un passage de messages.

- -

Nous pensons que ce compromis est logique pour plusieurs raisons :

- -

L'accès au DOM par le code de Firefox n'est pas commun.
Le code partagé avec Firefox OS utilise déjà le passage de messages.
Dans le modèle multi-processus, le code de Firefox qui ne parvient pas à utiliser le passage de messages afin d'accéder au contenu va échouer de manière évidente. Dans un modèle multi-threads, le code qui accède à du contenu sans blocage correct échouera de façon subtile, et sera bien plus difficile à déboguer.

- -

Sécurité

- -

Aujourd'hui, si quelqu'un découvre un bug exploitable dans Firefox, il est capable de prendre le contrôle des ordinateurs des utilisateurs. Il existe des solutions pour parer ce problème, la plus connue est la technique du bac à sable. Cette méthode ne nécessite pas une architecture multi-processus. Cependant, un bac à sable fonctionnant avec Firefox en processus unique ne serait pas très efficace. Les bacs à sable permettent seulement d'empêcher à un processus d'effectuer des actions qu'il ne devrait pas réaliser. Malheureusement, Firefox nécessite l'accès à bien plus de choses que le réseau et le système de fichiers (surtout lorsque des extensions sont installées). Ainsi, un bac à sable pour Firefox en processus unique ne pourrait pas bloquer grand-chose.

- -

Avec Firefox multi-processus, les processus contenus seront mis dans un bac à sable. Ainsi, un processus ne pourra pas accéder directement au système de fichiers, mais devra demander au processus principal. À ce moment, le processus principal pourra vérifier que la requête est sécurisée et logique. Par conséquent, le bac à sable peut être très restrictif. On espère que cette méthode rende plus difficile l'exploitation de trous de sécurité dans Firefox.

- -

Stabilité

- -

Actuellement, un plantage dans un code s'exécutant dans une page va faire tomber le navigateur en entier. Avec Firefox multi-processus, seul le processus du contenu qui s'est planté sera détruit.

- -

Cette page contient pas mal de contenu provenant de l'article de blog de Bill McCloskey's sur Firefox multi-processus : http://billmccloskey.wordpress.com/2013/12/05/multiprocess-firefox/ (en)

- -

diff --git a/files/fr/mozilla/firefox/multiprocessus_firefox/technical_overview/index.html b/files/fr/mozilla/firefox/multiprocessus_firefox/technical_overview/index.html deleted file mode 100644 index 92839d64e2..0000000000 --- a/files/fr/mozilla/firefox/multiprocessus_firefox/technical_overview/index.html +++ /dev/null @@ -1,164 +0,0 @@ ---- -title: Vue d'ensemble technique -slug: Mozilla/Firefox/Multiprocessus_Firefox/Technical_overview -translation_of: Mozilla/Firefox/Multiprocess_Firefox/Technical_overview ---- -

Cette page est une traduction d'un extrait de l'article du blog Bill McCloskey sur Firefox et le multiprocessus: http://billmccloskey.wordpress.com/2013/12/05/multiprocess-firefox/

- -

À un haut niveau, le Firefox en multiprocessus fonctionne comme il suit. Le processus qui est démarré quand Firefox est lancé est appelé le processus parent. Initialement, ce processus fonctionne de la même manière que Firefox lorsqu'il fonctionne avec un seul processus: une fenêtre est ouverte affichant browser.xul, qui contient les éléments principaux de l'UI pour Firefox. Firefox a un toolkit pour les GUI appelé XUL qui permet aux éléments de l'interface d'être déclaré et posés de façon déclarative, de la même manière que pour du contenu web. Tout comme le contenu web, il y a un objet window, qui a une propriété document, et celui-ci contient tout les éléments XML déclarés dans browser.xul. Tous les menus, barres d'outils, sidebars, et onglets dans Firefox sont des éléments XML dans ce document. Chaque onglet contient un élément <browser> pour afficher le contenu web.

- -

Le premier endroit où Firefox multiprocessus diverge de sa version en monoprocessus est que chaque élément <browser> a un attribut remote="true". Quand un tel élément est ajouté au document, un nouveau processus, appelé child process, pour le contenu est lancé. Un canal IPC est créé qui relie processus parent et enfant. Initialement l'enfant affiche about:blank, mais le parent peut envoyer des commandes à l'enfant pour naviguer autre part.

- -

Rendu

- -

D'une certaine manière, le contenu Web affiché doit passer du processus enfant au parent, puis à l'écran. Le multiprocessus de Firefox dépend d'une nouvelle fonctionnalité appelée off main thread compositing (OMTC). En bref chaque fenêtre de Firefox est divisée en séries de couches, en quelque sorte similaire au calque de Photoshop. Chaque fois que Firefox effectue un rendue de la page Web, ces couches sont soumises à un thread de composition qui traduit les couches et les associent en semble pour former la page qui est ensuite dessinée.

- -

Les calques sont structurés comme un arbre. La couche racine de l'arbre est responsable de l'ensemble de la fenêtre de Firefox. Cette couche contient d'autres couches, dont certaines sont responsables de l'élaboration des menus et des onglets. Une sous-couche affiche tout le contenu Web. Le contenu Web lui-même peut être divisé en plusieurs couches, mais ils sont tous enracinés dans une seule couche "content".

- -

Dans le multiprocessus de Firefox, la sous-couche de la couche de contenu est en fait une cale. La plupart du temps, il contient un noeud de substitution qui conserve simplement une référence à la liaison IPC avec le processus enfant. Le processus de contenu conserve l'arborescence de couches réelle pour le contenu Web. Il construit et dessine dans cet arbre de couche. Lorsqu'il a terminé, il envoie la structure de son arbre de couche au processus parent via IPC. Les tampons de sauvegarde sont partagés avec le parent soit par la mémoire partagée, soit par la mémoire GPU. Les références à cette mémoire sont envoyées dans une parti de l'arborescence de l'arbre. Lorsque le parent reçoit l'arborescence de la couche, il supprime son nœud de substitution et le remplace par l'arbre réel du contenu. Ensuite, il compose et dessine comme d'habitude. Lorsqu'il a terminé, il remet sont nœud de substitution.

- -

L'architecture de base de la façon dont OMTC fonctionne avec plusieurs processus existe depuis un certain temps, car il est nécessaire pour Firefox OS. Cependant, Matt Woodrow et David Anderson travail beaucoup pour que tout fonctionne correctement sur Windows, Mac et Linux. L'un des grands défis pour le multiprocessus de Firefox serait d'utiliser OMTC sur toutes les plates-formes. À l'heure actuelle, seuls la plate-forme Mac l'utilisent par défaut.

- -

User input

- -

Events in Firefox work the same way as they do on the web. Namely, there is a DOM tree for the entire window, and events are threaded through this tree in capture and bubbling phases. Imagine that the user clicks on a button on a web page. In single-process Firefox, the root DOM node of the Firefox window gets the first chance to process the event. Then, nodes lower down in the DOM tree get a chance. The event handling proceeds down through to the XUL <browser> element. At this point, nodes in the web page’s DOM tree are given a chance to handle the event, all the way down to the button. The bubble phase follows, running in the opposite order, all the way back up to the root node of the Firefox window.

- -

With multiple processes, event handling works the same way until the <browser> element is hit. At that point, if the event hasn’t been handled yet, it gets sent to the child process by IPC, where handling starts at the root of the content DOM tree. The parent process then waits to run its bubbling phase until the content process has finished handling the event.

- -

Inter-process communication

- -

All IPC happens using the Chromium IPC libraries. Each child process has its own separate IPC link with the parent. Children cannot communicate directly with each other. To prevent deadlocks and to ensure responsiveness, the parent process is not allowed to sit around waiting for messages from the child. However, the child is allowed to block on messages from the parent.

- -

Rather than directly sending packets of data over IPC as one might expect, we use code generation to make the process much nicer. The IPC protocol is defined in IPDL, which sort of stands for “inter-* protocol definition language”. A typical IPDL file is PNecko.ipdl. It defines a set messages and their parameters. Parameters are serialized and included in the message. To send a message M, C++ code just needs to call the method SendM. To receive the message, it implements the method RecvM.

- -

IPDL is used in all the low-level C++ parts of Gecko where IPC is required. In many cases, IPC is just used to forward actions from the child to the parent. This is a common pattern in Gecko:

- -

void AddHistoryEntry(param) {
-  if (XRE_GetProcessType() == GeckoProcessType_Content) {
-    // If we're in the child, ask the parent to do this for us.
-    SendAddHistoryEntry(param);
-    return;
-  }
-
-  // Actually add the history entry...
-}
-
-bool RecvAddHistoryEntry(param) {
-  // Got a message from the child. Do the work for it.
-  AddHistoryEntry(param);
-  return true;
-}
-

- -

When AddHistoryEntry is called in the child, we detect that we’re inside the child process and send an IPC message to the parent. When the parent receives that message, it calls AddHistoryEntry on its side.

- -

For a more realistic illustration, consider the Places database, which stores visited URLs for populating the awesome bar. Whenever the user visits a URL in the content process, we call this code. Notice the content process check followed by the SendVisitURI call and an immediate return. The message is received here; this code just calls VisitURI in the parent.

- -

The code for IndexedDB, the places database, and HTTP connections all runs in the parent process, and they all use roughly the same proxying mechanism in the child.

- -

Frame scripts

- -

IPDL takes care of passing messages in C++, but much of Firefox is actually written in JavaScript. Instead of using IPDL directly, JavaScript code relies on the message manager to communicate between processes. To use the message manager in JS, you need to get hold of a message manager object. There is a global message manager, message managers for each Firefox window, and message managers for each <browser> element. A message manager can be used to load JS code into the child process and to exchange messages with it.

- -

As a simple example, imagine that we want to be informed every time a load event triggers in web content. We’re not interested in any particular browser or window, so we use the global message manager. The basic process is as follows:

- -

// Get the global message manager.
-let mm = Cc["@mozilla.org/globalmessagemanager;1"].
-         getService(Ci.nsIMessageListenerManager);
-
-// Wait for load event.
-mm.addMessageListener("GotLoadEvent", function (msg) {
-  dump("Received load event: " + msg.data.url + "\n");
-});
-
-// Load code into the child process to listen for the event.
-mm.loadFrameScript("chrome://content/content-script.js", true);
-

- -

For this to work, we also need to have a file content-script.js:

- -

// Listen for the load event.
-addEventListener("load", function (e) {
-  // Inform the parent process.
-  let docURL = content.document.documentURI;
-  sendAsyncMessage("GotLoadEvent", {url: docURL});
-}, false);
-

- -

This file is called a frame script. When the loadFrameScript function call runs, the code for the script is run once for each <browser> element. This includes both remote browsers and regular ones. If we had used a per-window message manager, the code would only be run for the browser elements in that window. Any time a new browser element is added, the script is run automatically (this is the purpose of the true parameter to loadFrameScript). Since the script is run once per browser, it can access the browser’s window object and docshell via the content and docShell globals.

- -

The great thing about frame scripts is that they work in both single-process and multiprocess Firefox. To learn more about the message manager, see the message manager guide.

- -

Cross-process APIs

- -

There are a lot of APIs in Firefox that cross between the parent and child processes. An example is the webNavigation property of XUL <browser> elements. The webNavigation property is an object that provides methods like loadURI, goBack, and goForward. These methods are called in the parent process, but the actions need to happen in the child. First I’ll cover how these methods work in single-process Firefox, and then I’ll describe how we adapted them for multiple processes.

- -

The webNavigation property is defined using the XML Binding Language (XBL). XBL is a declarative language for customizing how XML elements work. Its syntax is a combination of XML and JavaScript. Firefox uses XBL extensively to customize XUL elements like <browser> and <tabbrowser>. The <browser> customizations reside in browser.xml. Here is how browser.webNavigation is defined:

- -

<field name="_webNavigation">null</field>
-
-<property name="webNavigation" readonly="true">
-   <getter>
-   <![CDATA[
-     if (!this._webNavigation)
-       this._webNavigation = this.docShell.QueryInterface(Components.interfaces.nsIWebNavigation);
-     return this._webNavigation;
-   ]]>
-   </getter>
-</property>
-

- -

This code is invoked whenever JavaScript code in Firefox accesses browser.webNavigation, where browser is some <browser> element. It checks if the result has already been cached in the browser._webNavigation field. If it hasn’t been cached, then it fetches the navigation object based off the browser’s docshell. The docshell is a Firefox-specific object that encapsulates a lot of functionality for loading new pages, navigating back and forth, and saving page history. In multiprocess Firefox, the docshell lives in the child process. Since the webNavigation accessor runs in the parent process, this.docShell above will just return null. As a consequence, this code will fail completely.

- -

One way to fix this problem would be to create a fake docshell in C++ that could be returned. It would operate by sending IPDL messages to the real docshell in the child to get work done. We may eventually take this route in the future. We decided to do the message passing in JavaScript instead, since it’s easier and faster to prototype things there. Rather than change every docshell-using accessor to test if we’re using multiprocess browsing, we decided to create a new XBL binding that applies only to remote <browser> elements. It is called remote-browser.xml, and it extends the existing browser.xml binding.

- -

The remote-browser.xml binding returns a JavaScript shim object whenever anyone uses browser.webNavigation or other similar objects. The shim object is implemented in its own JavaScript module. It uses the message manager to send messages like "WebNavigation:LoadURI" to a content script loaded by remote-browser.xml. The content script performs the actual action.

- -

The shims we provide emulate their real counterparts imperfectly. They offer enough functionality to make Firefox work, but add-ons that use them may find them insufficient. I’ll discuss strategies for making add-ons work in more detail later.

- -

Cross-process object wrappers

- -

The message manager API does not allow the parent process to call sendSyncMessage; that is, the parent is not allowed to wait for a response from the child. It’s detrimental for the parent to wait on the child, since we don’t want the browser UI to be unresponsive because of slow content. However, converting Firefox code to be asynchronous (i.e., to use sendAsyncMessage instead) can sometimes be onerous. As an expedient, we’ve introduced a new primitive that allows code in the parent process to access objects in the child process synchronously.

- -

These objects are called cross-process object wrappers, frequently abbreviated to CPOWs. They’re created using the message manager. Consider this example content script:

- -

addEventListener("load", function (e) {
-  let doc = content.document;
-  sendAsyncMessage("GotLoadEvent", {}, {document: doc});
-}, false);
-

- -

In this code, we want to be able to send a reference to the document to the parent process. We can’t use the second parameter to sendAsyncMessage to do this: that argument is converted to JSON before it is sent up. The optional third parameter allows us to send object references. Each property of this argument becomes accessible in the parent process as a CPOW. Here’s what the parent code might look like:

- -

let mm = Cc["@mozilla.org/globalmessagemanager;1"].
-         getService(Ci.nsIMessageListenerManager);
-
-mm.addMessageListener("GotLoadEvent", function (msg) {
-  let uri = msg.objects.document.documentURI;
-  dump("Received load event: " + uri + "\n");
-});
-mm.loadFrameScript("chrome://content/content-script.js", true);
-

- -

It’s important to realize that we’re send object references. The msg.objects.document object is only a wrapper. The access to its documentURI property sends a synchronous message down to the child asking for the value. The dump statement only happens after a reply has come back from the child.

- -

Because every property access sends a message, CPOWs can be slow to use. There is no caching, so 1,000 accesses to the same property will send 1,000 messages.

- -

Another problem with CPOWs is that they violate some assumptions people might have about message ordering. Consider this code:

- -

mm.addMessageListener("GotLoadEvent", function (msg) {
-  mm.sendAsyncMessage("ChangeDocumentURI", {newURI: "hello.com"});
-  let uri = msg.objects.document.documentURI;
-  dump("Received load event: " + uri + "\n");
-});
-

- -

This code sends a message asking the child to change the current document URI. Then it accesses the current document URI via a CPOW. You might expect the value of uri to come back as "hello.com". But it might not. In order to avoid deadlocks, CPOW messages can bypass normal messages and be processed first. It’s possible that the request for the documentURI property will be processed before the "ChangeDocumentURI" message, in which case uri will have some other value.

- -

For this reason, it’s best not to mix CPOWs with normal message manager messages. It’s also a bad idea to use CPOWs for anything security-related, since you may not get results that are consistent with surrounding code that might use the message manager.

- -

Despite these problems, we’ve found CPOWs to be useful for converting certain parts of Firefox to be multiprocess-compatible. It’s best to use them in cases where users are less likely to notice poor responsiveness. As an example, we use CPOWs to implement the context menu that pops up when users right-click on content elements. Whether this code is asynchronous or synchronous, the menu cannot be displayed until content has responded with data about the element that has been clicked. The user is unlikely to notice if, for example, tab animations don’t run while waiting for the menu to pop up. Their only concern is for the menu to come up as quickly as possible, which is entirely gated on the response time of the content process. For this reason, we chose to use CPOWs, since they’re easier than converting the code to be asynchronous.

- -

It’s possible that CPOWs will be phased out in the future. Asynchronous messaging using the message manager gives a user experience that is at least as good as, and often strictly better than, CPOWs. We strongly recommend that people use the message manager over CPOWs when possible. Nevertheless, CPOWs are sometimes useful.

diff --git a/files/fr/mozilla/firefox/privacy/index.html b/files/fr/mozilla/firefox/privacy/index.html deleted file mode 100644 index 3b51c404fe..0000000000 --- a/files/fr/mozilla/firefox/privacy/index.html +++ /dev/null @@ -1,15 +0,0 @@ ---- -title: Privacy -slug: Mozilla/Firefox/Privacy -tags: - - Privacy - - Security -translation_of: Mozilla/Firefox/Privacy ---- -

- -

Ce document liste la documentation relative à la confidentialité.

- -

diff --git a/files/fr/mozilla/firefox/privacy/protection_contre_le_pistage/index.html b/files/fr/mozilla/firefox/privacy/protection_contre_le_pistage/index.html deleted file mode 100644 index f466aef11f..0000000000 --- a/files/fr/mozilla/firefox/privacy/protection_contre_le_pistage/index.html +++ /dev/null @@ -1,79 +0,0 @@ ---- -title: Protection contre le pistage -slug: Mozilla/Firefox/Privacy/protection_contre_le_pistage -tags: - - Bloquage - - Pistage - - Privé - - Vie privée -translation_of: Mozilla/Firefox/Privacy/Tracking_Protection ---- -

Qu'est-ce que la protection contre le pistage ?

- -

Depuis la version 42, Firefox pour bureau et Firefox pour Android incluent une protection contre le pistage. En navigation privée, Firefox bloque le contenu chargé depuis des domaines qui pistent les utilisateurs à travers les sites.

- -

Certains contenus bloqués font partie de la mise en page, et les utilisateurs pourraient constater des problèmes de mise en page lorsque Firefox bloque ces chargements. Parfois, lorsque la page fonctionne de telle manière que d'autres éléments remplissent les espaces laissés par les éléments bloqués, les utilisateurs ne remarqueront rien.

- -

Quand Firefox bloque un contenu, il écrit un message dans la console web comme ceci :

- -

The resource at "http://some/url" was blocked because tracking protection is enabled.

- -

Notez qu'avec Firefox pour Android, vous pouvez accéder à la sortie de la console en utilisant le debogueur distant.

- -

L'interface utilisateur de Firefox indiquera aux utilisateurs quand un contenu a été bloqué et leur permet de le débloquer pour la session en cours s'ils le souhaitent. Les utilisateurs pourront aussi désactiver complêtement les protections contre le pistage s'ils le souhaitent.

- -

Comment Firefox choisit quoi bloquer ?

- -

Le contenu est bloqué selon le domaine à partir duquel il est chargé.

- -

Firefox contient une liste de sites qui ont été identifiés comme étant engagés dans une politique de suivi des utilisateurs au travers des différents sites visités. Quand la protection anti-tracking est activée, Firefox bloque le contenu provenant des sites de cette listes.

- -

Les sites surveillant les utilisateurs sont, le plus souvent, des sites tiers de publicité et d'analyse.

- -

Ce que cela signifie pour votre site

- -

Bien évidemment, cela signifie que quand la protection anti-pistage est activée:

- -

le contenu fourni par les pisteurs tiers ne sera pas visible par les utilisateurs
votre site ne pourra pas utiliser les services de publicité et d'analyse de sites tiers qui pratiquent le pistage.

- -

Plus subtilement, si d'autres parties de votre site dependent de pisteurs pour être chargés, alors ces parties ne seront pas fonctionnelles quand la protection anti-pistage est activées. Par exemple, si votre site inclus un rappel qui se lance quand le contenu d'un site de pistage est chargé, alors le rappel ne sera pas utilisé.

- -

Par exemple, vous ne devez pas utiliser Google Analytics de cette façon :

- -

<a href="http://www.example.com" onclick="trackLink('http://www.example.com', event);">Visit example.com</a>
-<script>
-function trackLink(url,event) {
-    event.preventDefault();
-    ga('send', 'event', 'outbound', 'click', url, {
-     'transport': 'beacon',
-     'hitCallback': function() {
-       document.location = url;
-     }
-   });
-}
-</script>

- -

A la place, vous devez prendre en compte le cas où Google Analytics est manquant vérifiant si l'objet `ga` est initialisé :

- -

<a href="http://www.example.com" onclick="trackLink('http://www.example.com', event);">Visit example.com</a>
-<script>
-function trackLink(url,event) {
-    event.preventDefault();
-    if (window.ga && ga.loaded) {
-         ga('send', 'event', 'outbound', 'click', url, {
-         'transport': 'beacon',
-         'hitCallback': function() { document.location = url; }
-       });
-    } else {
-        document.location = url;
-    }
-}
-</script>
-

- -

Pour plus d'information sur cette technique : Google Analytics, Privacy, and Event Tracking.

- -

A noter qu'être dependant de l'utilisation de l'outil tiers de cette manière n'est pas une bonne pratique, car cela veut dire que votre site peut être cassé si l'outil tiers est lent ou inaccessible, ou si le tracker est bloqué par un add-on.

diff --git a/files/fr/mozilla/firefox/privacy/protection_du_pistage_par_rebond/index.html b/files/fr/mozilla/firefox/privacy/protection_du_pistage_par_rebond/index.html deleted file mode 100644 index 1e93b3b26b..0000000000 --- a/files/fr/mozilla/firefox/privacy/protection_du_pistage_par_rebond/index.html +++ /dev/null @@ -1,101 +0,0 @@ ---- -title: Protection contre le pistage par redirection -slug: Mozilla/Firefox/Privacy/protection_du_pistage_par_rebond -tags: - - Firefox - - Mozilla - - Vie privée - - bounce tracking - - protection contre le pistage par redirection - - redirect tracking -translation_of: Mozilla/Firefox/Privacy/Redirect_tracking_protection ---- -

- -

Firefox 79 inclut une protection contre le pistage par redirection. Ce document décrit le fonctionnement de ces protections.

- -

Définition du pistage par redirection

- -

Le pistage par redirection est un abus de la navigation intersite dans lequel un traqueur redirige momentanément un utilisateur ou une utilisatrice vers son site web dans le but d’utiliser le stockage de première partie (first-party) pour suivre cet utilisateur ou cette utilisatrice à travers les sites web.

- -

Les navigations intersites sont une caractéristique essentielle du web. Une personne peut rechercher les « meilleures chaussures de course » sur un moteur de recherche, cliquer sur un résultat de recherche pour lire des critiques et enfin cliquer sur un lien pour acheter une paire de chaussures dans un magasin en ligne. Dans le passé, chacun de ces sites web pouvait intégrer des ressources provenant du même traqueur, et le traqueur pouvait utiliser ses cookies pour relier toutes ces visites de page à la même personne. Afin de protéger la vie privée des utilisateurs et utilisatrices de Firefox, la Protection renforcée contre le pistage (ETP pour Enhanced Tracking Protection) empêche déjà les traqueurs d’utiliser des cookies lorsqu’ils sont intégrés dans un contexte tiers, mais leur permet toujours d’utiliser des cookies en tant que première partie, car le blocage des cookies de première partie provoque le dysfonctionnement de sites web. Le pistage par redirection en profite pour contourner le blocage des cookies de tiers.

- -

Les traqueurs de redirection fonctionnent en vous obligeant à faire une escale imperceptible et momentanée sur leur site web dans le cadre de ce voyage. Ainsi, au lieu de naviguer directement du site web de comparaison au détaillant, vous finirez par naviguer d’abord vers le traqueur de redirection plutôt que vers le commerçant. Cela signifie que le traqueur est chargé en tant que première partie. Le traqueur de redirection associe les données de pistage aux identifiants qu’il a stockés dans ses cookies de première partie et vous achemine ensuite vers le commerçant.

- -

La protection contre le pistage par redirection expliquée

- -

Pour protéger contre le pistage par redirection, Firefox supprime périodiquement les cookies et données de site provenant des traqueurs. Nous effaçons uniquement ces données du stockage si l’utilisateur ou l’utilisatrice bloque les cookies traqueurs (c.-à-d. que la préférence network.cookie.cookieBehavior est réglée sur 4). La prise en charge d’autres politiques de cookies est suivie dans le bug 1643045.

- -

Quelles origines sont supprimées ?

- -

Une origine sera supprimée si elle remplit les conditions suivantes :

- -

Elle a stocké des cookies ou a accédé à un autre stockage de site (comme localStorage, IndexedDB ou Cache API) dans les dernières 72 heures. Comme les cookies sont assignés par hôte, nous supprimerons les variantes d’origine http et https d’un hôte de cookies.
L’origine est répertoriée en tant que traqueur dans la liste de notre protection contre le pistage.
Aucune origine disposant du même domaine de base (eTLD+1) n’a de permission d’interaction avec l’utilisateur ou l’utilisatrice. -
- Cette permission est accordée à une origine pour 45 jours dès qu’un utilisateur ou une utilisatrice interagit avec un document de premier niveau de cette origine. Une « interaction » peut être un défilement.
- Bien que cette autorisation soit stockée à un niveau par origine, nous vérifierons si une origine ayant le même domaine de base l’a, pour éviter de casser les sites avec des sous-domaines et une configuration de cookies correspondante.
-

- -

Quelles données sont supprimées ?

- -

Firefox supprimera les données suivantes :

- -

les caches réseau et image
les cookies
AppCache
DOM Quota Storage (localStorage, IndexedDB, ServiceWorkers, DOM Cache, etc.)
les notifications Push du DOM
les rapports de l’API Reporting
les paramètres de sécurité (comme HSTS)
les données des plugins de média EME (Encrypted Media Extensions)
les données des plugins (comme Flash)
les appareils média
les permissions de Storage Access accordées à l’origine
les tokens d’authentification HTTP
le cache d’authentification HTTP

- -

Note : même si nous effaçons toutes ces données, nous ne marquons actuellement les origines pour suppression que lorsqu’elles utilisent des cookies ou d’autres moyens de stockage du site.

- -

La suppression du stockage ignore les attributs d’origine. Cela signifie que le stockage sera supprimé dans les containers et le stockage isolé (comme celui de l’isolement de la première partie (First-Party)).

- -

À quelle fréquence les données sont-elles supprimées ?

- -

Firefox efface le stockage en fonction du déclenchement d’un événement interne appelé idle-daily, qui est défini par les conditions suivantes :

- -

Il sera, au plus tôt, déclenché 24 heures après le dernier événement idle-daily déclenché.
Il sera seulement déclenché si l’utilisateur ou l’utilisatrice a été inatif·ve pour au moins 3 min (pour 24-48 h après le dernier idle-daily) ou 1 min (pour > 48 h après le dernier idle-daily).

- -

Cela signifie qu’il y a au moins 24 heures entre chaque effacement de stockage et que le stockage sera uniquement effacé quand le navigateur est inactif. Lorsque nous supprimons des cookies, nous classons les cookies par date de création et nous les regroupons par lots de 100 (contrôlés par la préférence privacy.purge_trackers.max_purge_count) pour des raisons de performance.

- -

Débogage

- -

Le pistage par redirection peut être activé et désactivé en inversant la préférence privacy.purge_trackers.enabled dans about:config. En outre, il ne fonctionnera que si la préférence network.cookie.cookieBehavior est réglée sur 4 ou 5 dans Firefox 79+ (1, 3, 4, ou 5 à partir de Firefox 80).

- -

Différents niveaux de journalisation peuvent être déterminés grâce à la préférence privacy.purge_trackers.logging.level.

- -

Pour le débogage, il est plus facile de déclencher l’effacement du stockage en déclenchant le service directement par la ligne de commande de la console du navigateur. Remarquez que c’est différent de la console web que vous pouvez utiliser pour déboguer un site web et cela nécessite que la préférence devtools.chrome.enabled soit réglée sur true pour l’utiliser interactivement. Une que vous avez activé la console du navigateur, vous pouvez déclencher la suppression du stockage en exécutant la commande suivante :

- -

await Components.classes["@mozilla.org/purge-tracker-service;1"].getService(Components.interfaces.nsIPurgeTrackerService).purgeTrackingCookieJars()

- -

L’intervalle de temps jusqu’à ce que les permissions d’interaction avec l’utilisateur ou l’utilisatrice expirent peut être réglé à un niveau inférieur grâce à la préférence privacy.userInteraction.expiration. Notez que vous aurez à régler cette préférence avant de consulter les sites que vous désirez tester – elle ne s’appliquera pas rétroactivement.

- -

Autres mises en œuvre

- -

WebKit a livré en premier la protection contre le pistage par redirection dans ITP 2.0 (ils se réfèrent à la même attaque en l’appelant pistage par rebond (bounce tracking)). À compter de juillet 2020, il y a plusieurs différences importantes entre la mise en œuvre dans WebKit et dans Firefox :

- -

La liste des origines à effacer dans Firefox est basée notre liste de la protection contre le pistage, alors que WebKit s’appuie sur la classification d’ITP.
La définition d’« interaction » de Firefox comprend le défilement contrôlé par l’utilisateur ou l’utilisatrice lors de la visite de l’origine comme première partie, alors que WebKit non.
Firefox ne supprimera de données pour une origine s’il a reçu une interaction comme première partie dans les 45 derniers jours calendaires. La fenêtre d’interaction de WebKit est de 30 jours d’utilisation du navigateur (p. ex. les jours au cours desquels l’utilisateur ou l’utilisatrice a eu au moins une interaction avec Safari).

diff --git a/files/fr/mozilla/firefox/versions/14/index.html b/files/fr/mozilla/firefox/versions/14/index.html deleted file mode 100644 index 95e45a7a02..0000000000 --- a/files/fr/mozilla/firefox/versions/14/index.html +++ /dev/null @@ -1,90 +0,0 @@ ---- -title: Firefox 14 pour les développeurs -slug: Mozilla/Firefox/Versions/14 -tags: - - Firefox - - Firefox 14 -translation_of: Mozilla/Firefox/Releases/14 ---- -

Firefox 14, basé sur Gecko 14.0, est sorti le 17 juillet 2012. Cette page résume les principaux changements dans Firefox 14 qui sont utiles aux développeurs.

- -

Changements pour les développeurs Web

- -

HTML

- -

L'élément {{HTMLElement("progress")}} n'est plus classé à tort comme un élément de formulaire, et n'a donc plus l'attribut form.
Les touches de modification par défaut pour l'accesskey du contenu HTML sur Mac sont modifiées en Control + Option. C'est la même chose que sur les navigateur basés sur WebKit sur Mac.

- -

DOM

- -

Les évènements input sont aussi déclenchés sur l'édition d'un élément hôte de l'éditeur contenteditable et de l'élément racine de l'éditeur designMode.
{{domxref("DOMException", "DOMException.code")}} est à présent obsolète par la dernière spécification DOM 4.
La méthode {{domxref("Range.insertNode()")}} fonctionne désormais correctement lorsqu'elle est utilisée sur des gammes effondrées.
L'interface {{domxref("BlobBuilder", "MozBlobBuilder")}} a été abandonnée au profit du constructeur {{domxref("Blob")}}. Si vous utilisez MozBlobBuilder vous verrez un message d'avertissement dans la console Web.
Le support pour les observateurs de mutation a été lancé. Il est conçu pour remplacer les événements de mutation dans DOM3, ayant de nombreuses questions concernant la performance.
Les propriétés x et y de l'interface {{domxref("HTMLImageElement")}} ont été retirées dans Gecko 7.0 {{geckoRelease("7.0")}} mais restaurées dans cette version pour des raisons de compatibilité.
Les méthodes execCommandShowHelp() et queryCommandText() de {{ domxref("Document") }}, qui n'ont jamais rien fait, ont été retirées.
L'interface GeoPositionAddress, un élément obsolète de l'API Geolocation, a été supprimée.
{{domxref("Storage", "localStorage/sessionStorage")}} retourne désormais correctement undefined au lieu de null pour les clés non déclarées grâce à la propriété d'accès.

- -

CSS

- -

Les propriétés CSS {{cssxref("text-transform")}} et {{cssxref("font-variant")}} ont été corrigées pour gérer correctement les i → İ et ı → I des langues Turc.
Le digramme Hollandais IJ est à présent correctement géré par text-transform: capitalization. De même que la lettre grecque Σ, qui a deux formes minuscules, σ et ς, est à présent correctement géré par text-transform: lowercase.
Le support de la fonction skew() a été retiré de la propriété {{cssxref("transform")}}, comme elle a été supprimée du standard.
La syntaxe pour {{cssxref("border-image")}} a été mise à jour pour correspondre à la dernière version de la spécification ; elle n'accepte plus de slash ("/").

- -

MathML

- -

La syntaxe de l'action statusline sur les éléments {{MathMLElement("maction")}} a été ajustée pour correspondre à la spécification MathML.

- -

HTTP

- -

Gecko supporte à présent le nouveau code d'état HTTP 308 Permanent Redirect. Comme Gecko ne fait pas la différence entre les redirection permanentes et temporaires, elle se comporte comme le code d'état 307 Temporary Redirect, car elle interdit l'agent utilisateur de modifier la méthode HTTP utilisée entre les deux demandes (POST restera POST, GET restera GET).

- -

Changements pour les développeurs de Mozilla et de modules complémentaires

- -

Modules de code JavaScript

- -

source-editor.jsm

- -

Ajout d'un raccourci clavier pour basculer en commentaire la sélection actuelle (Ctrl-/ ou Cmd-/ sur Mac OS X).
Ajout de raccourcis clavier (Ctrl-[ et Ctrl-]) pour déplacer la position du curseur de texte au début et à la fin du bloc actuel.
Ajout de nouvelles méthodes getLineStart() et getLineEnd().

- -

XUL

- -

Ajout du nouvel attribut {{XULAttr("fullscreenbutton")}} à l'élément {{XULElem("window")}} ; la valeur true ajoute un bouton à la fenêtre de chrome pour activer le mode plein écran.

- -

Interfaces

- -

L'interface {{interface("nsILocalFile")}} a été intégrée dans {{interface("nsIFile")}} {{bug(682360)}}.
Les méthodes dans {{interface("nsIPlacesImportExportService")}} pour importer des marques-pages ont toutes été retirées en faveur du module de code JavaScript BookmarkHTMLUtils.jsm.
L'interface {{interface("nsIDOMGeoPositionAddress")}} a été supprimée.
Les méthodes getItemGUID, setItemGUID et getItemIdForGUID ont été retirées de l'interface {{interface("nsINavBookmarksService")}} ({{bug(715355)}}).

- -

Vérification orthographique

- -

Les noms du dictionnaire sont désormais analysés comme des étiquettes de langues BCP 47 ({{bug(730209)}}, {{bug(741842)}}). Les développeurs sont encouragés à ne pas coder le nom de leur langue en dur dans leur dictionnaire de noms.

- -

Voir également

- -

-- cgit v1.2.3-54-g00ecf