Greasemonkey: WebExt: Admite todas las API de GM

bug1323433 y bug1332273 pueden ser de interés aquí.

Gracias por los consejos, estoy de acuerdo en que ambos son muy útiles.

¡Oh, tal vez sea posible cierta cantidad de paso de mensajes sincrónicos!

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/runtime/onMessage#Sending_a_synchronous_response

Prueba esto. ¿Esto hace posible usar una implementación síncrona simple (respaldada por API solo en segundo plano) para los métodos mencionados anteriormente?

Eso devuelve una promesa en el lado del contenido, por lo que es efectivamente asíncrono. Creo que "sincrónico" es un nombre inapropiado aquí, es más como emparejar un mensaje de niño a padre con una respuesta para que uno no tenga que realizar un seguimiento manual de las respuestas pendientes.

Afaik, la única API síncrona disponible son los XHR de sincronización que luego podrían interceptarse con una solicitud web o algo así.

Sync XHR no funciona correctamente en el script de contenido: https://bugzilla.mozilla.org/show_bug.cgi?id=1360968, por lo que en este momento no tenemos ningún canal de sincronización de contenido > fondo.

Parece que GM_setValue y GM_getValue se diseñaron como operación de sincronización y en el navegador de un solo proceso funcionan bien cuando operamos en varias pestañas, pero en e10s no (https://github.com/greasemonkey /greasemonkey/temas/2427). Con la antigua API de extensión se puede reparar fácilmente, pero en WebExt no. Sin el mensaje de sincronización (incluso para datos pequeños, solo emite un valor corto) no podemos sincronizar correctamente el valor entre más pestañas. en algún momento esto siempre será una condición de carrera.

Independientemente de cómo resuelva los problemas anteriores en la versión WebExt, deberíamos obtener un nuevo método set/get diseñado de manera asíncrona, por lo que es importante que podamos escribir el script de forma asíncrona. Las documentaciones deben tener alguna información sobre el comportamiento de falta de GM_setValue y GM_getValue cuando se opera en varias pestañas.

En mi opinión, es raro que se usen GM_setValue / GM_getValue en varias pestañas y se deba seguir el orden. como resultado, el almacenamiento de una copia (caché) de _GM_values_ en la secuencia de comandos de contenido, la lectura siempre desde la memoria caché, la reescritura asíncrona y la actualización de la memoria caché con eventos activados por la secuencia de comandos en segundo plano deberían ser una solución aceptable.

por cierto, si es así, agregar una API equivalente a GM_addValueChangeListener es genial si es posible. (y no me gusta el nombre addValueChangeListener algo más debería ser mejor tal vez

En mi rama dev hay un apoyo para:

• GM.getResourceURL
• GM.deleteValue , GM.getValue , GM.listValues , GM.setValue

Planeo nunca agregar :

• GM_log
• GM_addStyle

Todavía necesitamos :

• GM_xmlhttpRequest

Planeo retrasar (o tal vez descartar):

• GM_registerMenuCommand (este siempre ha sido un gran costo de soporte)
• GM_getResourceText

Lo que significa que el progreso aquí está bastante cerca.

Buenos comentarios en el compromiso anterior, no lo olvides.

Acabo de probar el nuevo complemento. Parece que la solicitud xhr entre dominios ya se había habilitado sin las funciones GM_xhr. ¿Es esto realmente un comportamiento?

Simplemente intente con un script de usuario que no conceda ninguno con los siguientes códigos:

fetch(prompt()).then(resp => resp.text()).then(text => alert(text)).catch(error => alert(error));

Uf, confirmado. Actualmente estamos ejecutando secuencias de comandos de usuario como "secuencias de comandos de contenido", de la extensión, con todos los permisos de la extensión.

He investigado esto un poco, pero hasta ahora no sé cómo ejecutar un código sin privilegios ("alcance web", ¿cómo llamamos a esto ahora que el alcance del "contenido" es ambiguo?!). Lo más parecido que puedo encontrar es sobre la creación de etiquetas de script, que pueden/serán bloqueadas por el CSP de la página, lo que definitivamente no quiero.

Actualmente, la única forma de modificar CSP es interceptar y modificar los encabezados de cada solicitud de documento. Hay problemas abiertos para eximir a las extensiones web de los CSP de contenido, pero no parece haber mucha actividad al respecto.

Además de la inyección de <script> etiquetas window.eval también debería funcionar en el ámbito de la página, creo.

Los términos oficiales son "ámbito de script de contenido" frente a "ámbito de página".

Otro problema es que necesitarían procesamiento de cadenas para envolverlos en un ámbito separado que podría definir las API de GM.

También archivé un error para Sandbox equivalentes en extensiones web, pero tampoco es de alta prioridad.

Tanto el script como la evaluación de AIUI son vulnerables al bloqueo por parte de CSP. Pero he confirmado que eval pierde privilegios.

https://bugzilla.mozilla.org/show_bug.cgi?id=1391669

Debemos tener <all_urls> si vamos a ejecutar potencialmente un script de contenido en cualquier página. Si lo solicitamos, nuestro script de contenido lo obtiene y, por lo tanto, puede XHR a cualquier lugar.

Al menos en Firefox ( https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Content_scripts#Using_eval ()_in_content_scripts ) podemos desplegarnos hasta el alcance de la página, pero luego estamos realmente en el alcance de la página y no puede exponer de forma segura las API al script sin exponerlo a nada/todo lo que se ejecuta en la página (AFAIK), lo que es aún peor.

¿Se pueden sobrescribir fetch y xhr en el script de contenido?
Tal vez proporcione una búsqueda modificada que haga su propia verificación CORS.

• GM.xmlhttpRequest() se agregó en 60a50d05b1e565571d8a3e638b0683a1a9c2beaa
• GM.getResourceText() se cubrirá en #2548
• GM.registerMenuCommand() se está omitiendo intencionalmente.
• Cada secuencia de comandos que hereda la búsqueda de origen cruzado (según el comentario anterior) es # 2549

@the8472 Vea mi implementación de withUnsafeWindow() en https://github.com/greasemonkey/greasemonkey/issues/2232#issuecomment -326841025

Imita el comportamiento de la antigua función with (object) ... , solo que un poco más segura. (Necesita navegadores modernos).

@arantius escribió el 25 de julio :

Planeo nunca agregar :

GM_log
GM_addStyle

Estos se indicaron en la creación de este ticket (por @arantius el 3 de marzo ) como triviales (suponiendo una asignación de GM_log a console.log).

En mi experiencia, estas son dos de las llamadas API más utilizadas. ¿Abandonarlos no rompería muchos guiones viejos sin razón? ¿O te referías exclusivamente a la rama de desarrollo?

En Tampermonkey, GM_addStyle tiene una habilidad especial para inyectar estilo que puede eludir la restricción de CSP (en caso de que <style> esté prohibido). Estaré encantado si podemos tener esta característica en Greasemonkey también.