Greasemonkey: Ajouter une API GM.addStyle, pour styliser les pages CSP restrictives

Créé le 22 nov. 2017  ·  14Commentaires  ·  Source: greasemonkey/greasemonkey

le manque actuel de style de script est en fait un désastre complet :-(

Commentaire le plus utile

Merci !

Cependant cela rend le manque actuel encore plus incompréhensible...

Tous les 14 commentaires

addStyle n'est que 12 lignes de code triviales , que vous pouvez facilement copier-coller dans votre script. Ou même 11, car cette ligne n'est pas nécessaire :
style.setAttribute('type', 'text/css');

Merci !

Cependant cela rend le manque actuel encore plus incompréhensible...

@arantius J'ai un problème à essayer de charger des styles utilisateur sur des pages qui ont CSP et n'autorisent pas "self" comme origine - je ne peux donc pas simplement ajouter un élément <style> . GM pourrait résoudre ce problème en exposant une API qui appelle tabs.insertCSS() ( ref ). Les pensées?

J'ai un problème à essayer de charger des styles utilisateur sur des pages qui ont CSP et n'autorisent pas "self" comme origine - je ne peux donc pas simplement ajouter un

J'ai déposé un bug contre Stylish car c'est là que j'ai rencontré le problème. Néanmoins, j'ai pensé que cela pourrait valoir la peine d'être considéré ici, car les API actuelles de GM exposent principalement des API WebExt privilégiées qui contournent certaines restrictions de script de contenu ou autres, et insertCSS en est une autre.

Trouvé le bogue auquel @Sxderp fait référence (également celui-ci ). Lorsque ceux-ci atterriront, mes suggestions ici et sur Stylish seront inutiles.

Je ne sais pas exactement ce que signifie "Cela devrait fonctionner si vous regroupez le CSS dans votre extension..." dans le bogue lié. L'insertion de nœud dynamique peut ne pas fonctionner.

Je vais rouvrir pour considérer la fonctionnalité CSP-safe. (Mais à une priorité vraiment basse...)

En principe, cela pourrait également être implémenté sans attendre FF en transmettant un message au script d'arrière-plan et en exécutant tabs.insertCSS . Mais sauter à travers ces cerceaux ne sera plus nécessaire une fois ce bogue implémenté.

@arantius 1415352 dit "Cela devrait s'appliquer à la fois aux attributs HTML style et au contenu des nœuds HTML <style> ."

Au cas où il n'y aurait pas de plan pour ajouter un GM.addStyle (ce qui est très bien pour moi si le problème CSP est résolu autrement), je suggère de modifier cet article de blog pour préciser que non seulement « À partir d'aujourd'hui, il y a pas de support pour […] GM_addStyle", mais qu'aucun n'est prévu à l'avenir (et peut-être aussi pointer vers cette alternative ). Cela peut sembler évident, mais ce n'était pas pour moi (si je n'avais pas trouvé ce problème, j'attendrais peut-être que la fonctionnalité soit réimplémentée au lieu de corriger mes scripts maintenant).

Merci!

Concernant le polyfill : depuis que j'ai entendu dire que GM_addStyle était sur le billot, je n'ai en fait utilisé que 3 commandes pour le remplacer. Plutôt que de tester HEAD, j'ajoute simplement le STYLE directement au documentElement, qui est toujours présent, même au début du document.

var style = document.createElement('style'); var style.textContent = `
<Stylesheet here>
`; document.documentElement.appendChild(style);

Voici la version de la fonction que j'utilise plus rarement, qui s'exécute sur 5 lignes :

addStyle = function (css) {
  var style = document.createElement('style');
  style.textContent = css;
  document.documentElement.appendChild(style);
  return style; //optional, but convenient for changing the styling later.
};

J'ai testé cela dans GM 3 et 4 sur Firefox et TamperMonkey sur Chrome, sans problème, bien qu'il ne soit pas standard. Et je préfère que ce soit non standard qu'il échoue si le HEAD n'a pas encore été chargé (ce qui arrive étonnamment souvent. J'ai eu des plaintes.)

Je note également que UserStyles, org utilise ma méthode comme solution de secours dans ses scripts utilisateur générés automatiquement.

Plutôt que de tester HEAD, j'ajoute simplement le STYLE directement au documentElement, qui est toujours présent, même au début du document.

Dans FF57 et GM4, documentElement n'est pas toujours disponible au démarrage du document, du moins sur ma machine.

Étant donné que le GM 4 (pour l'instant) a commencé à documenter encore plus tard qu'avant, je suis
je ne sais pas comment c'est possible. Mais si le documentElement n'est pas présent,
alors ni l'un ni l'autre ne sera l'élément HEAD, puisque le documentElement est le
Élément HTML. qui est ce qui contient l'élément HEAD. Donc ma méthode n'est pas
pire.

J'avoue que je n'ai pas testé le dernier dev sur Fx 59, qui utilise un autre
méthode pour obtenir le démarrage du document, mais j'espère que le documentElement est présent. Si
non, alors toutes sortes de scripts se briseront. Vous ne pouvez rien faire au
document avant qu'il n'y ait un documentElement. Je ne pense même pas que tu puisses définir
jusqu'à des observateurs de mutation.

Je m'attendrais certainement à ce que l'élément document existe au moment où
tout script de contenu est injecté.

Le mardi 26 décembre 2017 à 18h26, CoolCmd [email protected] a écrit :

Plutôt que de tester pour HEAD, j'ajoute juste le STYLE directement au
documentElement, qui est toujours présent, même au début du document.
Dans FF57 et GM4, documentElement n'est pas toujours disponible sur
document-start, au moins sur ma machine.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/greasemonkey/greasemonkey/issues/2724#issuecomment-354028964 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AFNSrmb5eKj-nY9vnR3d94bq5kIjaz9Tks5tEY7PgaJpZM4QnG03
.

Je ne pense même pas que vous puissiez mettre en place des observateurs de mutation.

Vous pouvez attacher l'observateur de mutation à document .

Cette page vous a été utile?
0 / 5 - 0 notes