Greasemonkey: Permitir la instalación de archivos locales

¿Quizás esto (documentos de patrones de coincidencia)? El uso de * en el selector de coincidencias para el esquema solo se aplica a http o https. Sugiera agregar una coincidencia adicional por file:// .

Eso o el selector <all_urls> .

Agregar un patrón de coincidencia para detectar scripts file:/// solo hace que iniciemos un XHR que no puede leer el contenido en esa URL, lo cual es sorprendente.

He estado investigando esto un poco. Y he llegado a dos conclusiones. El problema puede tener que ver con no permitir el acceso del sistema de archivos a WebExtensions, incluso si es de solo lectura a través de XHR (no hay fuente sobre esto directamente; editar: aquí en la parte inferior). O podría estar relacionado con la política del mismo origen .

A partir de Gecko 1.9, los archivos solo pueden leer algunos otros archivos. Específicamente, un archivo puede leer otro archivo solo si el directorio principal del archivo de origen es un directorio principal del archivo de destino.

Podría valer la pena incluirlo en un informe de error para permitir el acceso del sistema de archivos a las rutas definidas en el manifiesto con el protocolo file:// .

Sí, probablemente sea la regla de "no archivos". No sé dónde obtener orientación oficial sobre eso, pero sé que es cierto ahora que lo pienso. Solo obtienes excepciones muy especiales como la API de descargas para crear archivos nuevos.

Podríamos intentar encontrar una solución alternativa como manejar directamente el arrastrar / soltar, o (LOL) leer el contenido de la pestaña que ya está abierta. Pero luego no podríamos obtener el ícono / recurso / requisitos relativos, por lo que aún no funcionará, sin aún más soluciones.

¿No podría usar storage.local para página de instalación ? Ya tienes el contenido en una variable. Por supuesto, el caché tendría que borrarse una vez instalado / definitivamente no instalado. Sería más conveniente si WebExtensions tuviera algún tipo de almacenamiento temporal para que no tengan que lidiar manualmente con el desalojo.

He estado jugando con lo que he dicho y no es tan sencillo como hubiera pensado. En primer lugar, cualquier script de usuario tiene acceso a browser.storage.local por lo que es inherentemente un almacenamiento inseguro para complementos como Greasemonkey. En segundo lugar, lo mismo ocurre con el envío del contenido a través de un mensaje a un script de fondo. No estoy realmente seguro de cómo asegurar eso para asegurar que el mensaje se envió solo desde script-detect.js . Y debido a la naturaleza asincrónica de los scripts, no estoy del todo seguro si script-detect.js ejecuta antes que los scripts de usuario (voy a hacer algunas pruebas sobre eso).

Y, por supuesto, a menos que me equivoque, los scripts de fondo no reciben ninguna referencia al DOM / contenido en ninguno de los oyentes de navegación.

Resulta que puede obtener el contenido de la página usando onBeforeRequest con una coincidencia en ['*://*/*.user.js'] y luego creando un StreamFilter . Implementé un código probando esto en mi rama recientemente publicada, no hay solicitud de extracción en este momento ya que no _ corrige_ nada. Sin embargo, evita las preocupaciones de seguridad que mencioné en mi publicación anterior.

Desafortunadamente, no resuelve el problema del archivo que se discutió. Algunas entradas de bugzilla en él:
https://bugzilla.mozilla.org/show_bug.cgi?id=1341341
https://bugzilla.mozilla.org/show_bug.cgi?id=1266960

Me dirigieron aquí desde el n. ° 2671

Si este hilo se trata de importar desde un archivo local ... entonces ...
¿Por qué utiliza XHR para leer un archivo local? Provoca todo tipo de complicaciones con orígenes y permisos.
La forma fácil es usar new FileReader() del resultado de input type="file"

Si este hilo se trata de reconocer file:///.....user.js URL como scripts e instalarlos, ese es el problema diferente y la solución diferente.

La forma más fácil es usar el nuevo FileReader () del resultado de input type = "file"

Ah, esto podría funcionar. No es tan elegante como navegar a una ruta file:// y hacer que la extensión haga todo por usted, pero podría funcionar. La mayor parte del flujo de trabajo podría seguir siendo el mismo.

import script -> script selected -> contents cached in backend -> install dialog prompt -> retrieve content from backend -> continue install as usual

Y es mucho más seguro que los métodos que estaba tratando de usar al intentar mantener el flujo de trabajo de navegación.

Encontré un ejemplo de extensión de web funcional usando "input type =" file "". Parece que no hay necesidad de almacenar en caché, se puede importar directamente:
https://github.com/mdn/webextensions-examples/pull/171/files/6c066cfff4e8c662984f704cb17c8b39211ed062#diff -098de1750b345156f3cfd46f8199aa34

Parece que no hay necesidad de almacenar en caché, se puede importar directamente

No es que el caché sea _necesario_, sino más bien una medida de seguridad. Al igual que cuando navega a un .user.js, aparece un cuadro de diálogo que le informa sobre el script. Creo que debería suceder lo mismo cuando realiza la importación. Por lo tanto, debe almacenar, en algún lugar que no sea la base de datos normal, el contenido del script para que, si el usuario hace clic en el botón de instalación, aún lo tendrá disponible y no tendrá que volver a preguntarle al usuario.

Si esto se almacena en caché usando una API de almacenamiento o simplemente en un objeto global en algún lugar, no importa particularmente para el flujo de trabajo.

También me gustaría decir que una función de importación debería convertirse en la máxima prioridad [1], ya que ayudaría a las personas que tienen problemas de migración. Solo pueden importar los archivos desde 3.x.

[1] Lo investigaría si @arantius tiene algunas ideas sobre cómo debería funcionar el proceso.

Tengo import./Export en varios de mis complementos si se necesitan ejemplos.

La importación la inicia el usuario, por lo que no es necesario tomar precauciones, ventanas emergentes, notificaciones o advertencias adicionales.

Agregue un botón de importación (entrada de archivo) a uno de los diálogos
Una vez que el usuario hace clic en él, se abre el selector de archivos. El usuario selecciona el archivo requerido y hace clic en abrir (todo HTTML5 integrado)
El archivo se lee y analiza
Si se ajusta a un script de usuario, se agrega al IDB
Luego actualice los oyentes en ejecución

Eso es todo....

Hago lo mismo en las preferencias de Importar / Exportar, Datos del tema (hasta 500kb) y muchos otros en mis complementos con la función de Importar / Exportar.

También me gustaría decir que una función de importación debería convertirse en la máxima prioridad [1]

De hecho ... eso permite a los escritores de scripts escribir nuevos scripts e importarlos para ejecutarlos o probarlos y, en el caso de la actualización GM3 -> 4, agregar los scripts perdidos.

El código y la función son muy simples ... pocas líneas de código que se pueden hacer en una hora.
Puede usar mi código como base si lo desea.

... La importación es iniciada por el usuario, por lo que no hay necesidad de precauciones / ventanas emergentes / notificaciones / advertencias adicionales. ... Si se ajusta a un script de usuario, se agrega al IDB

Aunque no estoy seguro de esto. En particular, no me gusta saltarme el diálogo de instalación estándar. Quizás @arantius pueda dar una idea de lo que le gustaría ver en el complemento.

Aunque no estoy seguro de esto. En particular, no me gusta saltarme el diálogo de instalación estándar.

El diálogo estándar se utiliza cuando el usuario se enfrenta a un script de usuario de una fuente remota. Entonces se necesita un diálogo de confirmación.

En caso de importación iniciada por el usuario:

• El usuario decide importar un script
• El usuario hace clic en el botón de importación
• El usuario navega al script seleccionado por el usuario.
• ¿Es necesario volver a preguntar al usuario con un diálogo "¿Realmente desea instalar este script?" :)
  Eso parece molesto. Sin embargo, es necesaria una advertencia en caso de errores.

• El usuario navega al script seleccionado por el usuario.

Pero esto no es así ... La instalación se realiza mediante devolución de llamada (activador en * .user.js) ...

Pero esto no es así ... La instalación se realiza mediante devolución de llamada (activador en * .user.js) ...

Actualmente sí. Pero es posible agregar un botón de importación para archivos locales. Y no realice la instalación en la navegación por file:// .

Ah, está bien, para archivos locales, eso es bastante apropiado. ¡No para archivos remotos! ;-)

Pero esto no es así ... La instalación se realiza mediante devolución de llamada (activador en * .user.js) ...

Como se mencionó, estamos hablando de la importación manual usando la entrada de archivos

Sí lo tengo. Eso está bien para mí para archivos locales (ver arriba) ...

Creo que es posible simplemente arrastrar y soltar el .user.js en la ventana de Greasemonkey para cargar el código del script en él.
Dado que esto definitivamente funciona para el propio Firefox (es decir, podría cargar un archivo en el sitio web, como imgur, o megaupload soltándolo)

¿Hay alguna forma (incluso una torpe, que no sea de arrastrar y soltar) que me permita importar scripts de GM locales?

¿En qué directorio "caché" deben colocarse finalmente los scripts? Encontré varios archivos de "caché" en el perfil de Firefox

Creo que es posible simplemente arrastrar y soltar el .user.js en la ventana de Greasemonkey para cargar el código del script en él.

Es posible, como cualquier otro buzón (consulte mi IMGoolge para ver un ejemplo). Sin embargo, la entrada de archivos directa sería el método más sencillo sin la necesidad de procesos y oyentes adicionales.

Mozilla actualizó el documento (resumen de los ejemplos anteriores):
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Working_with_files

1. Abrir archivos en una extensión usando un selector de archivos
2. Abrir archivos en una extensión usando arrastrar y soltar

Con esto implementado, tendríamos el mismo comportamiento que en GM3.

Entonces, ¿alguna posible sugerencia para instalar manualmente un script que no se ofrece en un formulario en línea adecuado?

@Samizdata Actualmente, la forma más fácil es obtener GM beta (https://addons.mozilla.org/en-US/firefox/addon/greasemonkey/versions/beta), abrir el menú de mono -> nuevo script.

Si tiene scripts que @requieren archivos locales, solo puede hacerlo de la manera difícil. Por ejemplo, tome Proxomitron (http://www.proxomitron.info/files/), ejecútelo, configure FF para usar el proxy 127.0.0.1:8080, coloque sus archivos en la carpeta HTML de Proxomitron y acceda a ellos luego dentro de FF con " http: //bweb..local.ptron/YOURFILE.user.js ".

@kekkc , creo que se ha

Salud. ¡Eso es todo, @kekkc !

@kekkc , creo que se ha
Todavía no ... por lo que puedo ver

@Sxderp ¿Nos referimos al # 2707?

@Eselce , sí. Eso _debería_ resolver los problemas presentes al crear una nueva secuencia de comandos con el botón 'nueva secuencia de comandos' y luego aplicar una etiqueta @require a la secuencia de comandos.

Para tener un .user.js o un script requerido que se sirve localmente, existen varias posibilidades. Pero la forma más fácil es usar esta línea de Python en su línea de comando:

• para Python 2.x:
  python -m SimpleHTTPServer

• para Python 3.x:
  python -m http.server

... que inmediatamente comienza a servir todos los archivos en el directorio donde lo ejecuta, en http://127.0.0.1:8000/

(_ tenga en cuenta que 8000 es el puerto predeterminado; puede cambiar eso; ver más abajo_)

Así es como pongo mi .user.js local y requiero archivos en un servidor http local. Hago esto para Greasemonkey pero también para Tampermonkey.

Python se instala de forma predeterminada en Linux y MacOs. Si estaría usando Windows y no lo tendría instalado y aún planea seguir llamándose desarrollador, entonces ... ¡¿En serio ?! ¿Qué te pasa? _ ¡Tienes problemas mucho más serios de los que te imaginas! Sugeriría jardinería: plántula: o tejer como pasatiempo en lugar de computadoras para ti: guiño: (_¡Ey, es broma! _)

No es necesario instalar ningún programa extraño; _ puede _, pero eso es _ absolutamente innecesario_. Python no es una "aplicación", es un lenguaje de programación fundamental. Pero ni siquiera necesita "hablar" en Python para esta solución, ¡así que no se rinda ni se apresure a utilizar sus herramientas de tejido todavía!

Procedimiento trivial:

1. cd en el directorio que contiene sus .user.js y / o los archivos requeridos. Digamos, por ejemplo, requiredFile1.js y requiredFile2.js

2. Desde ese directorio: para Python 2.x, ejecute

python -m SimpleHTTPServer

O: para Phython 3.x, ejecute

python -m http.server

1. Asegúrese de que sus líneas @require sean como estas:

// <strong i="42">@require</strong>  http://127.0.0.1:8000/requiredFile1.js
// <strong i="43">@require</strong>  http://127.0.0.1:8000/requiredFile2.js

... donde requiredFile1.js y requiredFile2.js son los archivos locales requeridos que desea servir.

1. Cuando su script greasemonkey se activa, recogerá correctamente los requisitos, que están siendo servidos por Python.

Hecho.

Para cerrar su servidor local, simplemente vaya a la consola donde ejecuta el comando python y presione <Ctrl><C> .

Además, -_- y espero que esto sea ridículamente obvio para usted _--, no olvide ejecutar la línea de comando del servidor HTTP de Python antes de esperar que Greasemonkey o Tampermonkey puedan encontrar los archivos ...

Sugerencia : Si desea utilizar un puerto que no sea el predeterminado 8000 , simplemente escriba el número deseado (un número de puerto válido) en su comando, así:

• para Python 2.x:
  python -m SimpleHTTPServer 12345

• para Python 3.x:
  python -m http.server 12345

... y, naturalmente, actualice las URL @require con ese número en lugar de 8000.

Ok, supongamos que hago clic en el icono de la barra de herramientas de GM y selecciono "Nuevo script de usuario ..."

La nueva pestaña correspondiente se denomina automáticamente "Script sin nombre 821696".

Luego pego el código GM de un archivo local en el panel de pestañas y hago clic en el icono "guardar" en la parte superior izquierda.

¿Dónde encuentro más adelante este script? Leer: ¿Cómo puedo editar este script más tarde?

¿Cómo puedo cambiar el nombre del script a, por ejemplo, "foobar"?

@bsto Name se tomará del script @name.
Todas las secuencias de comandos nuevas aparecerán encima de "Nueva secuencia de comandos de usuario ...".
Para eliminar o editar uno, haga clic en el título de la secuencia de comandos, habrá un submenú.

Está bien, gracias.

Solo otra pregunta:

El 25 de noviembre, el usuario kekkc nos dijo en su publicación (ver arriba) que Mozilla ofrecía una forma de arrastrar y soltar archivos (desde WinExplorer).

Por lo tanto, la función de arrastrar y soltar archivos de usuario debería ser posible ahora.

Estoy en lo cierto?

¿Cuándo se implementará en GM (disponible para arrastrar y soltar archivos * .user.js)?

FWIW Creo que podemos / deberíamos detectar la navegación a file://.../anything.user.js y adjuntar una acción de página que podría abrir una interfaz de usuario con cualquier tipo de explorador de archivos que podamos hacer que funcione.

Podemos detectar eventos de navegación pero no obtener contenido (tal vez en un script de contenido)

Aunque me parece una tontería navegar a un file:// solo para abrir un explorador de archivos (no creo que podamos hacer nada más que una entrada del selector de archivos).

Aunque me parece una tontería navegar a un archivo: // solo para abrir un explorador de archivos (no creo que podamos hacer nada más que una entrada del selector de archivos).

Sí, exactamente, estamos paralizados. Pero podemos detectar la intención y ser lo más útiles posible dentro de nuestro entorno limitado.

Mis 2 centavos ...

FWIW Creo que podemos / deberíamos detectar la navegación al archivo: //.../anything.user.js ,
Podemos detectar eventos de navegación pero no obtener contenido (tal vez en un script de contenido)

Como lo mencionó Sxderp, es posible pero un poco complicado ...

• Agregue un oyente (como tabs.onUpdated.addListener ya que necesitaría el contenido de todos modos)
• Deje que la página se cargue mostrando el script
• Inyecte la secuencia de comandos de contenido para capturar el contenido de la página y pasar a la secuencia de comandos bg
• Cerrar la página / pestaña

Alternativa ....

• Agregar un oyente de navegación
• Detenga la carga de la página y muestre una notificación para usar la opción de importación ... O ... una ventana emergente que muestra la opción de importación en la que el usuario debe hacer clic para iniciar el selector de archivos

Personalmente, si fuera yo, optaría por no agregar oyentes adicionales y simplemente agregaría la opción IMPORTAR a la ventana emergente del navegador.

Además, no he estado usando el formato .user.js desde GM4 de todos modos y creo que se puede dejar atrás. ;)

Personalmente, si fuera yo, optaría por no añadir oyentes extra y simplemente ..

Esto es lo que quise decir. Sin embargo, podría inyectar la interfaz de usuario en la página de contenido. Solíamos abrir una barra de información si navegaba a un script mientras GM estaba deshabilitado; esa clase de cosas.

Además, no he estado usando el formato .user.js desde GM4 de todos modos y creo que se puede dejar atrás. ;)

¿Qué significa esto?

¿Qué significa esto?

GM3 requería que los scripts fueran nombrados como abc.user.js para que pudieran ser reconocidos como script de GM.

En GM4, los scripts se guardan en IndexedDB y el nombre del script realmente no importa, ya que recibe el nombre de @name . Por lo tanto, he estado creando y guardando mis scripts (en la computadora) como abc.js (sin el .user ) y copiar / pegar en GM.

La IMPORTACIÓN manual, me imagino, no necesitaría estar vinculada al formato de nomenclatura .user .

¿Algún progreso en esto?

La extensión FireMonkey puede hacer esto:

https://addons.mozilla.org/en-US/firefox/addon/firemonkey/