Greasemonkey: Compatibilidad con WebExtension

He estado pensando mucho en esto. No tengo una "decisión" clara, pero algunos puntos:

• Acabamos de terminar con el proceso de migración para compatibilidad con e10s. Fue mucho más difícil cuando comenzamos; por ejemplo, Services.ppmm y .cpmm son buenos atajos, en los que hubiera sido bueno confiar desde el principio, pero no existían cuando comenzamos (responsablemente).
• Ese trabajo fue largo y muy doloroso, y no tengo muchas ganas de repetirlo de manera efectiva.
• El lanzamiento de e10s ha pasado de Firefox 36 (a septiembre de 2014) a Firefox 42 (a partir de ahora, septiembre de 2015), o al menos nueve meses.
• El anuncio dice que webextensions-only está al menos a 1 o 2 años; se deslizará a 2, 3, 4 años a partir de ahora?
• Si vamos a hacer esto, creo que es el momento adecuado para hacer una ruptura limpia y rediseñar.
  
  
  
  • Me encuentro deseando tener buenas pruebas unitarias con frecuencia, aunque tenemos muchos problemas que nunca detectarían, tenemos algunos que ellos también tendrían.
  
  
  • ¿Finalmente podemos agregar soporte para Android?
  
  
  • En realidad, no tenemos que volver a escribir desde cero, pero es posible que sea necesario reflexionar sobre qué código retenemos y cuál eliminamos.
  
  
• Realmente me encantaría tener una relación Greasemonkey / Mozilla mucho más sólida antes de comenzar otra tarea tan grande. Solo tengo conjeturas débiles sobre cómo hacer que eso sea una realidad.
  
  
  
  • Creo que hoy en día somos una prueba de tortura para portarnos a algo como webextensions; A lo largo de los años, hemos creado bastantes funciones avanzadas. Una comunicación bidireccional como parte del plan probablemente ayudará mucho.
  
  

Comenzar con un documento de diseño sería una gran idea. Esencialmente, necesitamos aplicar ingeniería inversa a todo Greasemonkey tal como existe en un plan de una buena manera, en lugar de una manera no planificada de cultivo orgánico, para que todo esté estructurado.

por ejemplo, Services.ppmm y .cpmm son buenos atajos, en los que hubiera sido bueno confiar desde el principio, pero no existían cuando comenzamos (responsablemente).

Ciertamente no estoy defendiendo el uso de WebExtensions todavía, son demasiado inmaduros para algo como GM.

En realidad, no tenemos que volver a escribir desde cero, pero es posible que sea necesario reflexionar sobre qué código retenemos y cuál eliminamos.

Hrm, bueno, lo estaba viendo principalmente desde un punto de vista tecnológico. En este momento, la interfaz de usuario utiliza superposiciones XUL y ejecución directa de scripts en el entorno de Chrome compartido.

Por lo tanto, convertir cosas a HTML y ejecutar cada una de ellas en un contexto de ventana independiente y solo comunicarse a través del paso de mensajes parece ser la forma en que se supone que se harán las cosas en el futuro.

El administrador de mensajes es básicamente el nivel más bajo en el que se implementa. Las abstracciones de nivel superior se basan en eso. Canales WebChannel.jsm / BroadcasstChannel / MessageChannel / WebExtension y demás.

Comenzar con un documento de diseño sería una gran idea.

¿La wiki de GH sería el lugar adecuado para eso? ¿Realiza notificaciones al editar para simplificar el trabajo colaborativo?

Creo que principalmente necesitamos una lista de características / plomería interna y cómo implementar cada una de manera limpia.

Si está interesado en el tema de este número, lea:

https://groups.google.com/d/topic/greasemonkey-dev/K6IyDUWnTQc/discussion

¡Gracias!

Pertinente:

• https://bugzilla.mozilla.org/show_bug.cgi?id=1271553
• https://bugzilla.mozilla.org/show_bug.cgi?id=1334174

https://developer.mozilla.org/en-US/docs/Web/API/File_and_Directory_Entries_API/Introduction

Esta es una API muy interesante, pero "esta característica no es estándar y no está en una pista de estándares" y la compatibilidad es muy limitada.

Todos mis intentos recientes (ver # 2483, # 2484) de diseñar Greasemonkey-under-WebExtensions con todas las funciones han sido frustrantes. Estoy empezando a considerar un estilo de desarrollo más progresivo: elija un conjunto más limitado de funciones y admita solo eso. Sea un poco útil y luego, con suerte, encuentre un camino hacia más funcionalidades más adelante.

Al inspeccionar mi instalación 3.x, veo que (para mí) cada script es <strong i="6">@grant</strong> none . De 27, solo seis usan @run-at document-start , y la mayoría de ellos funcionarían al menos con algo de gracia si eso no fuera compatible. La función @require se usa mucho, y @resource bastante.

Entonces, ese parece ser un objetivo decente al que apuntar primero: Admite scripts de usuario simples en el modo <strong i="12">@grant</strong> none , sin soporte para ninguna API de GM_ . Soporte @require . Espero apoyar @resource alguna manera, quizás de manera ineficiente.

(Nota al margen, porque sigo olvidándolo: planee usar @require en consideración.)

Tenemos acceso a API web simples además de las de WebExtension, por lo que:

https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API

? ¿Cuál es el límite de almacenamiento de IndexedDB para una WebExtension? Esta parece una opción mucho mejor que storage.local . La interfaz no es la más simple, pero nos da más poder para segregar scripts entre sí y hacer lecturas selectivas. Creo. Los documentos tampoco son los más fáciles de usar.

https://github.com/mdn/webextensions-examples/pull/171 parece tener una discusión valiosa y un ejemplo para IndexedDB

He hecho algunos progresos.

https://github.com/arantius/greasemonkey/tree/webbymonkey (en 88d53b4c67b7825858405eb2591f27c8487ce413)

Reimplementado desde cero. Verifique, vaya a about:debugging , presione "Cargar complemento temporal" y seleccione cualquier archivo de la ubicación raíz. Puede instalar y ejecutar scripts de usuario apenas. Absolutamente ninguna otra característica todavía. (Bueno, está el menú del mono, pero es una falsificación vacía que no hace nada más que verse bien). Muchos TODOs esparcidos alrededor del código incluso para este pequeño conjunto de características. No puedo garantizar que nada de esto sea el "camino correcto" hacia más funciones o no.

Dado que las versiones anteriores de Tampermonkey, así como Violentmonkey, son de código abierto, ¿podría usarse parte de ese código aquí, ya que WebExtensions es similar a Chromium Extensions?
EDITAR: En realidad, mirándolo, no estoy seguro de la compatibilidad de la licencia con el antiguo Tampermonkey. Pero Violentmonkey tiene licencia del MIT, por lo que es compatible.

@PorygonZRocks : ¿Violentmonkey se convierte en Greasemonkey?

No tengo mucha experiencia con la codificación, pero estaba pensando que al menos podría tener algunas pautas para implementar cosas. Una vez más, no tengo mucha experiencia / conocimientos, por lo que puedo estar equivocado.

Vale la pena señalar que FF56 deshabilitó todos los complementos que no son compatibles con multiprocesos, por lo que es posible que deba cambiar la fecha límite.

Ver mi rama de desarrollo . Lo cual es bastante tosco pero mínimamente funcional. Esto se está haciendo, no hay nada que rastrear específicamente en este tema de amplio alcance.

@arantius Por curiosidad, ¿estás escribiendo código nuevo o reutilizando el antiguo?

¿Necesitas ayuda?

De nuevo por curiosidad, por ejemplo, ¿el propósito de "parse-meta-line.js" es simplemente analizar los metadatos en un objeto?

@arantius Por curiosidad, ¿estás escribiendo código nuevo o reutilizando el antiguo?

Mayormente nuevo. Copiar cuando / donde sea útil. (Hasta ahora, el análisis de secuencias de comandos es un gran ejemplo).

¿Necesitas ayuda?

La ayuda estaría bien. Coordinar sería difícil.

De nuevo por curiosidad, por ejemplo, ¿el propósito de "parse-meta-line.js" es simplemente analizar los metadatos en un objeto?

Una línea, sí.

Una línea, sí.
Quiero decir, ¿hace algo más que analizar los metadatos entre estos:

// ==UserScript==
....
// ==/UserScript==

Parece mucho código si ese es el único objetivo.

Sí, eso es lo que hace. Es código generado. Lleve esta discusión a https://groups.google.com/d/topic/greasemonkey-dev .

No uso grupos de Google :(
Si fuera yo ... probablemente lo haría de manera diferente.

El grupo de google ya no existe.

Enlace incorrecto: https://groups.google.com/forum/#!forum/greasemonkey -dev

No estoy del todo seguro de si esta es la ubicación correcta, pero aquí está de todos modos. Si quieres que abra un número separado @arantius , seguro.
¿No se supone que 4.0.0 migrará los scripts existentes? Actualicé a alpha 3 (proveniente de la última versión no beta) y noté que ya no tenía scripts.

@Phyxion , si instala 3.14, los scripts deben migrarse. Asegúrese de reiniciar el navegador después de la instalación.

Después de eso, cuando instale 4.x, debería tener los scripts. Si no lo hace, serían útiles algunos pasos de reproducción detallados en un nuevo número.

Greasemonkey 4 alpha es incompatible con Firefox 57.

@erkinalp , ¿podrías

@Sxderp Bueno, reproducirlo en mi máquina es fácil. Tengo 3.14 instalado con 10 scripts de usuario. Vaya a AMO y descargue la última versión alfa. Reinicie cuando se le solicite. Entonces simplemente dice que no hay instalados los scripts de usuario. No estoy seguro de cuán útil es esto para reproducirlo.

Aún no lo he probado, pero creo que GM4 debería perder su configuración después de una desinstalación, mientras que GM3 debería mantenerla , así que le sugiero que intente:

1. Desinstalar completamente Greasemonkey
2. Reinicia Firefox
3. Instale Greasemonkey 3.14 (incluido el reinicio)
4. Reinicia Firefox por si acaso
5. Instale Greasemonkey 4 (puntee cualquier cosa)

¿Eso ayuda?

Creo que el nivel superior de espera, es decir, envolver todo en una función asíncrona, no es una buena opción de diseño ya que restringe implementaciones futuras (por ejemplo, si / cuando recuperamos los sandboxes o es-future realms). Hace que las cosas sean inconsistentes con la ejecución de Vanilla JS donde el nivel superior de espera no está disponible y los scripts se ejecutan ... bueno ... en un nivel superior.

@arantius
Todavía nada aquí :(
Por cierto, se supone que 4.0 se verá así: https://i.imgur.com/CPuWWKM.png
No hay botones ni nada para agregar un script.

... envolviendo todo en una función asincrónica ...

Con lo que está disponible ahora, "tengo" que ajustar una función para fines de alcance. Sin embargo, creo que compro tu razonamiento para no hacerlo asincrónico. (Al menos, agregar una función contenedora asíncrona en el script en sí es trivial).

Sí, se trataba principalmente de async / await, ya que actualmente no está permitido intencionalmente en javascript , por lo que habilitarlo en los scripts de usuario parece un peligro para cambios futuros. Sé que la envoltura es inevitable actualmente, pero espero que las cosas puedan volver al nivel superior en el futuro.

@arantius ¿

@arantius comentó en 2017. szept.

... envolviendo todo en una función asincrónica ...

Con lo que está disponible ahora, "tengo" que ajustar una función para fines de alcance. Sin embargo, creo que compro tu razonamiento para no hacerlo asincrónico. (Al menos, agregar una función contenedora asíncrona en el script en sí es trivial).

Intente eliminar el contenido de [perfil de mozilla] \ storage \ default \ (después de realizar una copia de seguridad)
Vuelva a intentarlo.

Hablando de objetos UserScript, no entiendo muy bien la decisión de diseño de tener tres clases de UserScript. Por el momento tienen un árbol de herencia singular que es un poco tonto.

Además, RemoteUserScript solo se usa una vez y para eso solo se crea para obtener la identificación . Y RunnableUserScript nunca se usa directamente.

Sólo por información ...

Estoy en FF57.0a1 y estoy ejecutando complementos heredados y GM 3.13
Lamentablemente, no recibo las actualizaciones (3.14, 3.15) ya que su versión máxima está configurada en 56. *

Sin embargo, se puede instalar manualmente.

GM 3.16 todavía cuelga el navegador al iniciarse (supongo que está actualizando la base de datos)