Realmente creo que esto debería repensarse. Tanto VM como TM se comportan de manera contraria a esto. Al navegar a una secuencia de comandos, se le presenta una página que incluye tanto el contenido / fuente de la secuencia de comandos como un botón de instalación. Aunque técnicamente es "redirigido", en esencia, todavía está "navegando" al script de usuario. ¿Quizás esto debería aparecer en la lista de correo -users y -dev y ver las opiniones que otros tienen?

Apoyo la discusión comunitaria.

Personalmente, soy de la opinión de que ~ nadie revisa la fuente, por lo que es una tontería mostrársela a todos los usuarios, incluida la mayoría que ni siquiera puede entenderla.

Y: revisar solo la fuente principal, cuando también hay un @require , logra muy poco.

Me entristecería mucho que no volviera a tener la posibilidad de revisar el código fuente. Siempre me siento más cómodo leyendo el código. Y si hay @require incluye que no apunta a una biblioteca bien conocida (jQuery oficialmente alojado, etc.), siempre soy escéptico y generalmente aborto la instalación a menos que realmente necesite ese script (en cuyo caso, hojeo el contenido de

Pero incluso si soy una excepción y la mayoría de las personas no miran ni comprenden el código, creo que hay un efecto preventivo para que los escritores de scripts sepan que se muestra la fuente al instalar.

En caso de que aún decida no mostrar el código fuente, agregue enlaces de fuente de visualización de fácil acceso que apunten al código fuente cuando instale un script (y preferiblemente también cualquier script @require incluido).

Como mencioné, también valoro la capacidad de revisión. Para la minoría de personas que lo deseen. Solo quiero que funcione como # 2567 para que pueda revisar _todo_ la fuente. Simplemente haga clic en editar después de la instalación y obtendrá todos los recursos de texto y fuente visibles. Habilite o desinstale como elija.

Existen algunas implicaciones de rendimiento al requerir múltiples solicitudes de red. Específicamente, entre su 3. y 4. está la "descarga hasta el punto en el que tenemos un metabloque válido, por lo que podemos abrir el cuadro de diálogo de instalación".

Digamos que el archivo no es un script de usuario real y no tiene un metabloque válido. El cuadro de diálogo de instalación nunca aparecerá. El único curso de acción que veo es reanudar la navegación. Una vez que se reanuda la navegación, el archivo debe volver a descargarse. Una solicitud innecesaria (# 2830 aborda esto expandiendo lo que se está haciendo actualmente en onHeadersReceived ).

Ya ha señalado este punto antes y debe considerarse. ¿Qué pasa si la conexión es lenta? Por ejemplo, digamos que se tardan 10 segundos en descargar el archivo. El usuario tendrá 10 segundos sin comentarios mientras GM intenta la descarga en busca de un script. Falla y se lo entrega al navegador para continuar con la navegación. Nuevamente otros 10 segundos descargando el archivo para su visualización.

No voy a decir que no hay forma de evitar esto. Por ejemplo, los datos podrían almacenarse en caché o algo así, y luego sobrescribir la salida en la navegación real. Pero siento que esto conduce a una complejidad de código innecesaria solo para proteger a los usuarios.

Alternativamente, puede abrir el cuadro de diálogo de instalación de todos modos y simplemente no instalar el archivo que no es de script (VM hace esto). Consideraría esa mala experiencia de usuario.

Si alguien puede encontrar una forma limpia de hacer esto sin las solicitudes adicionales, genial. De lo contrario, no puedo respaldar esto sin beneficios _actual_. [1]

[1] Has mencionado "poder revisar _todo_ el código fuente" debido al # 2567 como un beneficio potencial. Pero no estoy de acuerdo. Siento que el # 2567 debería ser una característica _independientemente_ de si el código fuente está disponible en la instalación o no.

No sé. Sobre otros temas he podido dar una respuesta después de un poco de discusión. Pero este es uno que no estoy "viendo".

Desde mi punto de vista, realmente no me importa si el script es visible de inmediato, pero creo que si cancelo la instalación o algo, debería poder ver el archivo sin procesar como lo haría si greasemonkey no estuviera instalado. Realmente no me importa si está oculto de forma predeterminada o algo así, pero alguna forma de descartar el cuadro de diálogo de instalación y volver al script parece fundamental.

No creo que tenga sentido interrumpir la visualización de cosas llamadas *.user.js . Esto está eliminando la funcionalidad del navegador.

Veo un script de usuario más como una extensión que como una página web. Tampoco navega nunca a una extensión. Lo descarga / instala, o no lo hace.

No creo que tenga sentido interrumpir la visualización de cosas llamadas * .user.js. Esto está eliminando la funcionalidad del navegador.

También está haciendo cosas como lo hacían las versiones anteriores de GM, incluido no tocar las navegaciones cuando está deshabilitado. Si necesita ver esto desesperadamente en su navegador, primero desactive GM.

Veo un script de usuario más como una extensión que como una página web. Tampoco navega nunca a una extensión. Lo descarga / instala, o no lo hace.

No estoy de acuerdo con este razonamiento. Una extensión es un paquete de archivos archivado. Un script de usuario no lo es. Podrías argumentar sobre @requires y @resources pero creo que eso es tenue. No todos los usan y muchos de ellos son solo texto sin formato. Cuando navega a una página de texto sin formato, generalmente (asumiendo que el encabezado de archivo adjunto / descarga no está configurado, lo que también me resulta molesto) no es necesario descargarlo antes de verlo.

También está haciendo cosas como lo hacían las versiones anteriores de GM.

Claro, pero no creo que este sea un gran argumento a favor o en contra de ninguna característica en particular. La versión anterior puede dar una línea de base, pero en el futuro creo que todo debería reexaminarse en nuevos contextos. Esto incluye la complejidad del código, los beneficios que inculca o no, los méritos, etc.

Tampoco navega nunca a una extensión. Lo descarga / instala, o no lo hace.

Ser un archivo de texto marca la diferencia. Por ejemplo, github tiene una opción "ver sin formato" que ahora está rota.

incluyendo no tocar navegaciones cuando está deshabilitado.

Esto es bueno saberlo. Supongo que podría haberlo adivinado, pero en realidad no es obvio. Estoy nervioso porque estaba tratando de ver un archivo y no se procesa. Tal vez podríamos proporcionar una pista al usuario de que esto se puede hacer cuando lo encuentre, en lugar de mostrar una página en blanco.

Valoro tomar decisiones de diseño que brinden el mayor valor a la mayoría de los usuarios, por lo que valoro las aportaciones.

Sin embargo, este será un caso raro en el que voy a poner mi pie en el suelo. No se moleste en debatir enfoques. Quiero el comportamiento de: hay un enlace a un script de usuario válido, hago clic en ese enlace, veo (solo) el cuadro de diálogo de instalación y nunca navego hasta un archivo de texto, nunca veo la fuente. Voy a hacer lo que sea necesario para que Greasemonkey actúe de esa manera. Período.

Antes de WebExt, obtuvimos esto usando http-on-modified-request , para suspender cualquier solicitud de búsqueda de script de usuario lo antes posible. Activaríamos el cuadro de diálogo de instalación e iniciaríamos una operación de cancelaría la solicitud que posee y ... algo reiniciaría la navegación (creo que reanudando el canal exactamente, pero No puedo encontrar eso).

Con un script lento , no sucede nada al principio; una vez que se carga la parte ==UserScript== , aparece el cuadro de diálogo de instalación, luego su barra de progreso se llena mientras se descarga el resto; el resto del script, el recurso, requiere etc.

Se las arregla para descargar el script con una sola conexión al servidor.

En WebExt, todas las API son diferentes, por supuesto, pero el evento de bloqueo / filtrado onHeadersReceived que ya está en HEAD _ parece ser lo mejor para usar. Todavía tengo que investigar.

Quiero el comportamiento de: hay un enlace a un script de usuario válido, hago clic en ese enlace, veo (solo) el cuadro de diálogo de instalación y nunca navego hasta un archivo de texto, nunca veo la fuente. Voy a hacer lo que sea necesario para que Greasemonkey actúe de esa manera.

Pero este es un cambio al antiguo comportamiento. GM 3.x Tuve la opción de hacer clic en ver fuente en lugar de instalar y luego no se instaló nada, pero obtuve una pestaña que mostraba la fuente de la secuencia de comandos. A partir de ahí tuve la posibilidad de instalar o simplemente cerrar la pestaña y no hacer nada. Este sería el comportamiento que al menos me gustaría volver a ver. Para mí no es necesario mostrar siempre la fuente, pero una opción para inspeccionarla antes de instalar algo como estaba antes, sería genial.

El motivo de esta solicitud es que vi el daño que pueden causar los scripts maliciosos y, por lo tanto, siempre inspecciono la fuente antes de instalar algo. Esta es la razón por la que también veo la actualización automática silenciosa como un problema, ya que podría traer nuevos códigos maliciosos al usuario.

Con webRequest puede devolver una URL falsa para abortar la carga y hacer que el navegador permanezca donde está. Pero al hacerlo, se cancela inmediatamente la conexión, no puede usar el filtro para observar / analizar / cambiar el contenido, por lo que deberá iniciar una nueva conexión. Creo que esto está bien en este caso, porque tenemos todos los datos que necesitamos (método de solicitud, encabezados de respuesta) en el alcance y, por lo tanto, podemos tomar una decisión segura sobre si esto realmente es un script de usuario o no, y también es muy temprano en el ciclo de solicitud.

Tuve la opción de ... inspeccionarlo antes de instalar nada ...

2567

¿Qué pasa si parece un script de usuario, pero no lo es? Por ejemplo, si toma su ejemplo de carga lenta y simplemente elimina el // ==UserScript== inicial. Ábralo en 3.x, el cuadro de diálogo de instalación nunca se abre (correcto) y luego el contenido de texto se escribe en la pestaña / página. Con WebEx, si crea una nueva conexión en segundo plano, no veo cómo puede escribir el contenido en la página. Hasta donde yo sé, la única forma directa de escribir contenido en una página en segundo plano es a través del filtro de flujo.

Puedo pensar en algunas formas de "solucionarlo". De nuevo, no hay buenas soluciones. Pase los datos a un script de contenido que simplemente hará eco del contenido (creo que debería ser factible). Redirigir a una página de extensión, pero eso romperá el historial. O hacer que FF reinicie la solicitud con alguna bandera configurada para ignorar la verificación del script. Pero esa es una tercera solicitud ...

Quizás me estoy perdiendo algo ...

Ábralo en 3.x, el cuadro de diálogo de instalación nunca se abre (correcto) y luego el contenido de texto se escribe en la pestaña / página.

Eh, me gustaría corregir este punto. Estaba equivocado, tuve un error tipográfico en user cuando probé inicialmente.

@Sxderp permítanme repetir que valoro mucho las contribuciones que han hecho hasta la fecha y espero que continúen.

Pero para tener un poco más de claridad en cuanto a mi decisión descrita anteriormente: he limpiado mi trabajo en progreso; primero moví un trabajo no relacionado a confirmaciones separadas . Lo que quedó es un cambio de nombre de archivo y luego esta gran confirmación , que es solo + 425-491.

La clase Downloader encapsula toda la lógica sobre (descargar e) instalar un script, independientemente de la fuente. Solo necesita configurar las entradas, solo la URL para una instalación, pero también la fuente del script principal y tal vez el contenido del recurso / requerimiento si ya lo conoce (para el caso de edición), descarga cualquier otra cosa que falte (es decir, edite en un nuevo requerimiento / resource) y pasa siempre un mismo formato a user-script-regstry que lo persiste de una sola manera. El downloader.js completo tiene menos de 250 líneas. Como resultado, se transmiten menos mensajes entre el fondo / contenido y no hay puertos nuevos.

Hay ocasiones en las que tiene mucho sentido dividir un gran fragmento de código complejo en fragmentos más pequeños y sencillos. Pero en mi opinión, esto no es todo. Los datos que fluyen son los mismos, ya sea que estemos instalando un "nuevo" script, actualizando uno o editando uno en su lugar. Solo cambian cosas menores (¿ya conocemos el UUID del script ya instalado? ¿Ya lo sabemos o necesitamos descargar esto o aquello?).

¿Esto también resuelve la estructura recursiva de parsedDetails (hay un problema en alguna parte, no tengo tiempo para buscarlo)?

No sé. ¿Lo dudo?

¿Esto también resuelve la estructura recursiva de parsedDetails (hay un problema en alguna parte, no tengo tiempo para buscarlo)?

¿Te refieres al número 2806?