Firefox // Manifest V3 //

Compliqués rapports entre firefox et le ManifestV3. Maintenant que le support est là (v109) et même dans les versions ESR, il restait pour moi le problème lié au permissions d’accéder à tous les sites. Dans le Manifest.json, cela ne suffit pas:

"host_permissions": ["<all_urls>"],

Grosse prise de tête donc je mets ici le résultat de mes explorations:

  1. Mettre dans le popup un bandeau pour avoir un point d’entrée, par exemple:
    <center id="perm" style="color: yellow; background: #840; clear: both; font-weight: 404; padding: .5em; margin,: .5em; cursor: pointer;">Finaliser</center>
  2. Dans le javascript du popup, mettre ce bout de code dans handler de l’event DOMContentLoaded avec pour objectif de cacher le bandeau défini précédemment si les permissions d’hôte sont bonnes, et sinon de les obtenir grâce à un clic sur le bandeau (action de l’utilisateur nécessaire):
    chrome.permissions.contains({
    origins: ['<all_urls>']
    }, (result) => {
    if (result) {
    document.getElementById('perm').style.display = 'none';
    } else {
    document.getElementById('perm').addEventListener('click',function() {
    chrome.permissions.request({
    origins: ['<all_urls>']
    }, (granted) => {
    if(!granted) {
    browser.permissions.request({
    origins: ['<all_urls>']
    });
    }
    });
    });
    }
    });

  3. Fonctionne aujourd’hui avec Firefox 119. Transparent pour browser moins regardants, type Chromium/Chrome.

Cheers

DOMParser()

Je travaille sur un addon pour différents browser donc avec du code oecuménique si possible. J’ai une liste d’ouvrages dont les noms contiennent des caractères accentués. Initialement la liste était dans la source (mauvaise idée) puis, après des déboires sur l’encodage de ces accents (JSON est explicitement encodé dans un certain charset, charset mentionné dans les headers, donc problème en local) (notoirement avec Safari), je suis passé à un fichier .xml inclus. Tout allait bien en utilisant un DOMParser() qui est la solution typique dans ce cas. (ceux qui font du innerHTML peuvent sortir). Reste qu’ensuite, sur ma route vers les bas-fonds, je suis tombé sur un problème avec Edge, en fin de tests de plates-formes.

Toujours est-il qu’Edge refuse mon script back (background/serviceworker) car selon lui « Uncaught (in promise) ReferenceError: DOMParser is not defined ». Edge est bien le seul à soulever une difficulté sur ce point. Sur mon chemin de croix vers une solution, je vois que certains, dans d’autres contextes inapplicables ici, utilisent new window.DOMParser(), on conséquence je finis par croire/comprendre que DOMParser() n’est pas disponible dans mon contexte de script d’arrière plan, un peu de la même manière qu’il n’est pas disponible pour un node.js, mode headless en quelque sorte.

https://stackoverflow.com/questions/68964543/chrome-extension-domparser-is-not-defined-with-manifest-v3

Bref, pas sympa. J’aurais sans doute dû passer par la nouvelle API offscreen mais bon, quelques regexps plus tard, j’étais sorti d’affaire car ma structure n’était pas compliquée. JSON/CSV/XML, la question ?

Dans le même ordre d’idée, les workers manifestV3 de Google Chrome ne supportent pas « URL.createObjectURL » ?

ManfestV3, notes dans la jungle

Je suis lancé dans l’écriture d’un add-on browser pour aller plus loin qu’un user-script (monkey).

Vu le climat actuel, je suis parti sur une web-extension, format manifestV3, histoire de partir sur de bonnes bases, ce malgré des documentations parfois obscures. Mon browser de test est bien évidemment Firefox, qui a introduit très récemment (v109) le support de ce nouveau format (donc les ESR doivent patienter).

Le projet fait que l’adaptation du développement aux navigateurs de types Chromium/Chrome/Edge se fait sans trop de problème de compatibilité, réduisant au final le travail à changer une ligne dans le manifest.json, remplacer « scripts »:[« scripts/back.js »] par « service_worker »: « scripts/back.js » pour avoir quelque chose qui tourne ce qui est très gratifiant. C’est pas très stable mais cela fonctionne.

Reste Safari que j’aime bien, mais pour lequel le développement et ses outils (Xcode) est bien différent à finaliser (xcrun safari-web-extension-converter). Quelle ne fut ma surprise quand j’ai constaté qu’avec la version actuelle, 16.3, il faut partir d’un manifest type Firefox et non celui des cousins de Safari mentionnés plus haut.