Greasemonkey: Agregar copia de seguridad / restaurar

Bueno, Firefox y sus problemas. Entonces, estaba implementando esto (y, por supuesto, una función de 'importación'). Ya casi termino, pero hay un obstáculo. Solo funciona cuando abres browser toolbox y seleccionas "no cerrar automáticamente las ventanas emergentes". La importación se realiza a través de <input type="file"> (que es la única forma), sin embargo, en el foco de la ventana de exploración, la ventana emergente normalmente se cierra, por lo que la ventana se destruye y no se ejecuta ninguna función. Errores relevantes:
https://bugzilla.mozilla.org/show_bug.cgi?id=1292701
https://bugzilla.mozilla.org/show_bug.cgi?id=1366330

Es muy molesto tener un entorno a medias en el que trabajar.

Además, se aplica a # 2612. Lo que se puede abordar al mismo tiempo que se trata este problema.

@Sxderp Si el cierre de la ventana emergente es un problema, la forma normal de solucionarlo es simplemente abrir una pestaña o ventana (apuntando a una página HTML dentro de la extensión) en la que realiza lo que sea necesario. Estas pestañas / ventanas no se cierran automáticamente y presentan el mismo entorno que una ventana emergente. Si bien eso puede no ser tan limpio como tenerlo todo dentro de la ventana emergente del navegador, debería ser funcional.

Yo podría hacer eso. Implicaría mover un montón de código. Lo investigaré en otro momento.

Completé las cosas de importación / exportación. Sin pruebas y muy poco manejo de errores. Pero funciona. Sin embargo, por simplicidad, lo hice para que una importación sobrescribiera toda la base de datos. Con un mensaje de confirmación, por supuesto.

Creo que idealmente el usuario podría optar por reemplazar o fusionar la importación. Stylus solo se fusiona, lo que también es un IME incorrecto. La elección del usuario, con valores predeterminados que podrían funcionar, parece mejor.

Claro, pero luego nos encontramos con muchos condicionales. Me gustaría ver un diagrama de flujo de algún tipo sobre la naturaleza _exacta_ de la fusión.

Sobre todo en términos de conflictos. ¿Sobrescribir contenido, sobrescribir clave / valores (sí, también se exportan), solicitar todo (parece una mala experiencia de usuario), etc.?

Me refiero simplemente a: importar cada script en el archivo (y sobrescribirlo completamente a ese estado), pero no toque / elimine los scripts que no están en el archivo.

Oh. Eso es mucho más sencillo. Sí, eso suena bien.

Así que implementé tres métodos de importación diferentes.

1. Unir. No toque ningún script instalado. Solo se agregarán a la base de datos los scripts que no existen actualmente [1].
2. Reemplazar. Desinstale todos los scripts actuales y reemplácelos con los importados.
3. Sobrescribir. Como fusionar, pero si se encuentra un conflicto [1], los scripts que se están importando tienen prioridad.

Esperando a otros RP antes de enviar.

[1] Determino la unicidad por id de un script.

¿Qué pasa con esto?

1. Actualizar. Solo importe (sobrescriba) scripts que ya existan.

Esto es complementario a 1. Fusionar

1. Sobrescribir. Como fusionar, pero si se encuentra un conflicto [1], los scripts que se están importando tienen prioridad.

@Sxderp Supongo que "Me gusta fusionar" no incluye la restricción "Solo scripts que no existen actualmente" ...
(esta restricción no tiene sentido aquí) Eso significa, Sobrescribir = Importar todos los scripts, los scripts en conflicto se sobrescriben en el archivo ...

¿Cuáles de estas opciones (actualizar / fusionar / etc.) ofrecen VM, TM u otras opciones?

1. Actualizar. Solo importe (sobrescriba) scripts que ya existan.

Seguro, eso debería ser factible.

Eso significa, Sobrescribir = Importar todos los scripts, los scripts en conflicto son sobrescritos por el archivo ...

Correcto.

¿Cuáles de estas opciones (actualizar / fusionar / etc.) ofrecen VM, TM u otras opciones?

En realidad no estoy seguro. Pero esto trajo a colación otra preocupación mía. Compatibilidad con archivos. Suponiendo que esos complementos admitan la exportación completa de la base de datos (scripts + datos), lo ideal es que las importaciones sean compatibles entre sí.

Actualizar. Solo importe (sobrescriba) scripts que ya existan.

Ahora que pienso en esto (como 3 minutos), tengo una preocupación. ¿Qué pasa con los datos asociados (get / setValue)? ¿Deben permanecer los datos almacenados actualmente? ¿Deben tener prioridad los datos importados? ¿Algún tipo de fusión? Y luego representar claramente esta opción / estado para el usuario. En realidad, esto es un poco más complicado que un primer vistazo.

Hice algunas comprobaciones rápidas, esto no es 100% completo, pero ofrece una descripción general, así como lo que probablemente debería cambiar con respecto a mi implementación.

VM y TM se exportan a archivos zip. Dentro de los archivos zip, puede encontrar archivos .user.js para cada uno de sus scripts. Sin embargo, en cuanto a la exportación de detalles específicos de almacenamiento / implementación, ambos lo hacen de forma un poco diferente. VM envuelve los detalles específicos de la implementación y los datos del script, para lo que parecen todos los scripts, en un solo archivo, violentmonkey . TM hace esto con un poco más de cordura. Los detalles específicos de la implementación, para cada script, se exportan a archivos .options.js , mientras que los datos del script se exportan a .storage.json .

Creo que voy a reelaborar mi implementación para seguir la MT. En general, creo que es un mejor estándar, ya que separa los detalles de implementación de los datos.

En cuanto al 'método de importación' (descrito en mi publicación anterior):

TM proporciona una interfaz de "seleccionar cada secuencia de comandos". Cuando importa un archivo, selecciona si desea importar cada script específico. Si lo marca, sobrescribirá todos los datos de ese script.

VM solo parece ofrecer lo que describí anteriormente como 'Sobrescribir'. Sin embargo, hay una opción para NO importar datos de secuencia de comandos asociados (global para todas las secuencias de comandos). Desde la perspectiva de la interfaz de usuario, creo que implementar esa opción en GM sería difícil. Sin embargo, si adoptamos el enfoque de TM para exportar / importar la base de datos, entonces un usuario podría simplemente abrir el archivo y eliminar el archivo .storage.json .

Si alguien quiere probar, he actualizado mi rama, sxderp:import-export-database-merge , para incluir la funcionalidad .zip que mencioné anteriormente. No implementé la opción update que sugirió @Eselce porque todavía no estoy seguro de los detalles.

@Sxderp Gracias por desarrollar esta función. Construí el paquete y lo instalé en Firefox Developer Edition (para permitir la instalación de extensiones sin firmar). Actualicé un perfil existente con esa versión del navegador, sobrescribí la instalación existente de GreaseMonkey y exporté mi base de datos sin ningún problema.

Sin embargo, la importación en un nuevo perfil de Firefox con este GreaseMonkey instalado causó un problema. Parece que un script de usuario específico que es bastante grande (tanto user.js como gm_details.js tienen alrededor de 230K está causando problemas de importación. Después de reemplazar la base de datos, GM deja de funcionar. Al hacer clic en el ícono de GM, se abre un menú desplegable vacío (aproximadamente 10x10 cuadrados).

Prefiero no compartir públicamente el script de usuario específico. Usando este truco , encontré tu dirección de correo electrónico y te enviaré un mensaje de esa manera.

Editar: la única forma de hacer que GM funcione después de que se rompe es eliminar la extensión, reiniciar Firefox y agregarlo nuevamente.

GMexport_20180 2 17_164139.zip ???

Importé un montón de (en parte) scripts grandes (> 20) de un archivo zip de 3.4 MB sin quejas. Sin embargo, no hay un examen detallado ...

  return 'GMexport_'
       + date.getFullYear().toString()
       + date.getMonth().toString().padStart(2, '0')
       + date.getDate().toString().padStart(2, '0')
       + '_'
       + date.getHours().toString().padStart(2, '0')
       + date.getMinutes().toString().padStart(2, '0')
       + date.getSeconds().toString().padStart(2, '0')
       + '.zip'

IIRC, getMonth() comienza en 0 ... ; falta ...

IIRC, getMonth () comienza en 0 ...; desaparecido...

ROTURA

No he trabajado en esta rama por un tiempo. Voy a tomar hoy y volver a basarme en el maestro y hacer un montón de limpieza.

He vuelto a basar mi rama en master e hice algunos cambios significativos en el diseño que creo que ofrece una mejor legibilidad.
@ArmEagle En mi rama actualizada pude importar el archivo que enviaste. Si sigues teniendo problemas, avísame y lo investigaré más a fondo.

Combinado con cambios en 7fe8bfe94efbadeb1da1a6491aaf424fc8275f09. Reapertura para rastrear / discutir algunos problemas que he visto.

Reapertura para rastrear / discutir algunos problemas que he visto.

¿Cuáles fueron los problemas?

Fue una prueba rápida única, no estoy seguro, alguna cantidad de script que esperaba instalar no estaba en la lista. Pero quiero repetirlo y realizar un seguimiento cuidadoso y anotar los resultados. Hay muchos casos posibles.

Finalmente lo he investigado un poco.

Realiza una copia de seguridad solo de .user.js y de los "detalles". Lo que pasa por incluir accidentalmente el contenido requerido, pero pierde los recursos (JSON serializa el blob hasta {} ). AFAICT .setKnownResources() con manchas vacías / rotas y, por lo tanto, no funcionará.

Parecería mejor si cada script tiene su propia carpeta, esa carpeta contiene un archivo para el .user.js , para cada @require y @resource , y luego quizás el resto analizado / detalles personalizados y valores almacenados. Creo que esto podría ser lo suficientemente mejor como para renunciar a cualquier compatibilidad multiplataforma.

Totalmente de acuerdo. Al igual que guardar un documento "como página web", lo que crearía un documento htm más una carpeta con el mismo nombre (base) con las dependencias ...

Lo que pasa a incluir accidentalmente el contenido obligatorio ...

No fue por accidente. Lo incluye a propósito, para cualquier cambio local que pueda haber ocurrido. Consideraría los recursos / requisitos como "detalles de implementación" y, por lo tanto, los exportaría como "detalles". TM ni siquiera exporta recursos / requiere.

pero pierde los recursos (JSON serializa el blob hasta {}). AFAICT .setKnownResources () con blobs vacíos / rotos y, por lo tanto, no funcionará.

Hay un TODO para averiguar si los blobs se encadenan bien. Esta función se fusionó técnicamente antes de enviar un PR para ella.

Por el momento, el problema de Blob se resolvería con # 2937.

En cuanto a la creación de más archivos en el archivo de respaldo, no creo que confiera todos los beneficios. Si bien archivar recursos y requisitos y lo que sea en archivos separados puede _ verse_ bien cuando se extraen, hacer esto probablemente haría que el código sea más complejo, ya que se trata de muchas cosas pequeñas en lugar de un simple volcado.

Esta es la "gran característica" de la versión 4.4, así que realmente espero terminar / mejorar esto pronto.

Segundo pensamiento, esto es funcional. Hay algunas mejoras de las que me gustaría realizar un seguimiento, pero un problema de cada uno de esos cambios específicos será más fácil de administrar.