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

Let it be dark in javascript

Au début on se dit qu’il faut questionner le choix utilisateur avec une mediaQuery:

 (window.matchMedia && window.matchMedia('(prefers-color-scheme: dark)').matches)

Reste que si l’on est dans un contexte incertain, développement d’un add-on dans mon cas, se résoudre à cette simple requête est une mauvaise stratégies car le site sur lequel on vient se pluger lui peut ne pas adapter son style aux choix utilisateur (dark mode ou non).

Sur Firefox qui est mon browser de dev, je ne comprenais pas pourquoi j’obtenais « rgba(0, 0, 0, 0) » avec la ligne suivante sur des pages où le fond est blanc mais le système est en dark mode:

window.getComputedStyle(document.body,null).getPropertyValue('background-color');

A vrai dire, mon erreur était de comprendre cette ligne comme parlant de la couleur noire (0,0,0) alors que le dernier 0 indique en rgba que le fond est transparent, or le fond d’écran d’une page web est blanc. La proprieté (‘background’) retourne d’ailleurs ‘none’. Chrome et safari retournent une valeur rgb qui est plus simple à comprendre.

Au final, je pense être pas mal avec ce bloc:

var dark = false;
let bs = window.getComputedStyle(document.body,null);
let baco = bs.getPropertyValue('background-color');
  if(bs.getPropertyValue('background') == 'none') {
  if(!(/rgba.*,\s?0\)$/.test(baco))) {
    dark = true;
  }
} else {
  let sacos = baco.split(/,/);
  let moy = 128;
  if((sacos != null) && (sacos.length > 2)) {
    moy = (parseInt(sacos[0].replace(/\D+/g,''))+parseInt(sacos[1].replace(/\D/g,''))+parseInt(sacos[2].replace(/\D/g,''))) / 3;
  }
 
  if((moy < 128) && !(/rgba.*,\s?0\)$/.test(baco))) {
    dark = true;
  }
}

Au final, j’aime bien mon petit calcul pour essayer d’évaluer si la couleur est plutôt sombre ou claire.

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.

Dans un browser, ça a l’apparence du web mais ce n’est pas du web

Faites une requête avec le mot « emprise » dans un moteur de recherche type google. Vous obtenez des résultats. C’est sur le web et dans un browser. Mon test pour dire que c’est du web est que c’est modifiable/remixable: par exemple:

document.evaluate('//text()[contains(.,"emprise")]',document.body,null,XPathResult.ORDERED_NODE_SNAPSHOT_TYPE);

Cela retourne des résultats avec lesquels ont peut jouer (console JS/DOM, user scripts, ..etc)

Par contre, si je vais sur docs.google.com, que je crée un document dans lequel je tape juste le mot « emprise », même en faisant attention à la case du texte, je n’obtiens rien avec le test précédent, mis à part un script de données qui contient ce même mot. En clair, il ne trouve pas de nodes textuelles contenant le mot en question. Et pour cause, l’affichage est en fait une balise canvas donc hors du DOM qui est l’essence du web/html. Autant mettre un binaire qui pointerai vers une VM. Ici le web n’est qu’un transport et le browser un simple réceptacle.

Ensuite le site en question trouve malin d’intercepter tous les événements clavier. Tout y passe sauf bien sûr ceux qui sont interceptés auparavant par le browser. Bref, on ne peux pas jouer ici. Ce n’est pas du web, désolé. Mauvais karma.