webNavigation. Si las opciones incluyesen la clave 'allFrames': true el problema estaría _algo_ resuelto. Cualquier marco en la página html estática tendrá la secuencia de comandos inyectada, aunque luego tendrá problemas de coincidencia de origen / URL. Además, si se crea un marco utilizando Javascript, el script no se inyecta.

La solución más fácil que se me ocurrió sería reemplazar webNavigation.onCommitted con webRequest.onResponseStarted con un filtro de {'urls': ['<all_urls>'], 'types': ['main_frame', 'sub_frame']} .

Hice algunas pruebas limitadas y no se necesitaron más cambios. Pude ejecutar un script dentro de un marco y un marco creado con Javascript.

@arantius ¿ algún plan para fusionar la solución de @Sxderp ?

Esto está afectando escenarios donde los iframes son objetos de origen cruzado, por lo que es imposible realizar ningún tipo de modificación sin ejecutar GM en esos iframes particulares.

Gracias !

Perdí esto, lo veremos pronto.

Solo una observación durante mi prueba de scripts antiguos, no sé, si ayuda ...

Dado un script, se supone que funciona en un iframe,
parece que ejecuta los cambios en la página,
pero luego se actualiza nuevamente a la página sin modificar.

Solo puedo ver el parpadeo cuando actualizo la página muy rápido.

Solo una observación durante mi prueba de scripts antiguos, no sé, si ayuda ...

¿Es esto con mi parche o con la versión lanzada?

Uf, creo que fue la versión 4.0 ...
ERA @ 4.1b3, pero para las pruebas, estoy bastante seguro de que reinstalé la versión de lanzamiento (¡hasta ahora!)

Lo mismo ocurre con los iframes como los describe Eselce. De alguna manera se ejecuta, pero luego se detiene después de que se carga el iframe o la página.

Si inyecto este script, solo obtengo 1 y "self! == top":

console.log('1');
if (self !== top) {
   console.log('self !== top');
   setTimeout(function() {
      console.log('Timeout');
   }, 2000);  
} else {
   console.log('self === top');
}

"Timeout" no se muestra en el registro, ni todas las funciones y enlaces.

Yo uso 4.1b3.

Tengo el mismo problema al ejecutar GM 4.0 en Quantum. Escribí un ejemplo ficticio muy simple con dos páginas: main.html y framed.html , y un script GM que se carga en cada página y genera la URL de la página en la que está cargada.

La mayoría de las veces, solo recibo notificaciones sobre main.html , pero en aproximadamente el 5% de los casos, especialmente si mantengo presionada la tecla F5, también puedo recibir una notificación sobre framed.html .

¿Existe algún truco para forzar de manera confiable a GM 4.0 a ejecutarse dentro de iframes hasta que salga un parche?

Acabo de descubrir que los scripts de usuario se ejecutan de manera confiable en <embed src="..."> pero no en <iframe src="..">
Escribí un pequeño guión de prueba:
https://openuserjs.org/scripts/cuzi/iframe_embed_Test_Greasemonkey_4

Algunos detalles más: en algunos casos, mis scripts se ejecutan completamente en el marco (pero la vista se sobrescribe más tarde con scripts de página, etc.).
A veces, las partes sincrónicas de mi secuencia de comandos terminan, pero las partes asincrónicas se interrumpen repentinamente por la actividad de la página ...
¡Espero que ayude!

¿Alguien tiene más información sobre esto?

Solo un breve resumen de este hilo (problema):

• Olvídese de la mayoría de las publicaciones, no se aplican
• Probablemente, los scripts se ejecutan siempre (pero no hasta el final)
• Desafortunadamente, la página se actualiza más tarde: el diseño se vuelve a calcular, la ejecución se cancela
• Esto se aplica principalmente (pero no del todo) a las partes asíncronas de los scripts

No me gustan mucho estos aspectos internos, pero probablemente alguien sí ...

Como solución temporal, he estado intercambiando iframes por incrustaciones ( script de ejemplo ), que funciona para obtener un script correspondiente al marco que se activará (crédito a @cvzi por descubrir que <embed src="..."> sí funciona) .

Vale la pena señalar que Violentmonkey y Tampermonkey funcionan bien dentro de los marcos incrustados. Dado que VM es de código abierto, tal vez vea cómo lo hicieron.

Desafortunadamente, Violentmonkey y Tampermonkey todavía usan el antiguo esquema de nomenclatura GM_ para las funciones especiales, por lo que los scripts aún no son portátiles.

https://github.com/greasemonkey/gm4-polyfill

Tampermonkey => GM. * Llamadas, si no se proporcionan
Violentmonkey => GM. * Llama
Greasemonkey -3.17 / FF -56.0 => GM. * Llama
Greasemonkey 4.0+ / FF 57.0+ => llamadas GM. * Integradas

// <strong i="11">@grant</strong>        GM.getValue
// <strong i="12">@grant</strong>        GM.setValue
// <strong i="13">@require</strong>      https://greasemonkey.github.io/gm4-polyfill/gm4-polyfill.js
// <strong i="14">@grant</strong>        GM_getValue
// <strong i="15">@grant</strong>        GM_setValue

¿La corrección de

¿La corrección de

1. No, no lo ha hecho.
2. Desafortunadamente, ese es uno de mis RP que no he mantenido sincronizado con el maestro y, por lo tanto, no se ha modificado. Entonces, a la rama misma le faltan algunos de los cambios actuales.
3. Tampoco implementé los cambios sugeridos en los comentarios de relaciones públicas. Honestamente, esos cambios _no deberían_ ser necesarios, pero debido a que Mozilla estropea las cosas continuamente, los cambios son necesarios.
4. Si aún desea usarlo (no recomendado), puede seguir los pasos a continuación.

1. git clone -b use-on-response-started-for-execute --single-branch https://github.com/Sxderp/greasemonkey.git [1]
2. Ejecute ./package.sh , esto creará un archivo XPI.
3. Vaya a about:config en Firefox y configure xpinstall.signatures.required en false
4. Vaya a about:addons en Firefox, haga clic en el engranaje y luego seleccione instalar desde el archivo.
5. Seleccione el XPI que se creó en el paso 2.

[1] Si su versión de git no es compatible con las banderas -b y / o --single-branch (versión anterior de git), puede hacer git clone https://github.com/Sxderp/greasemonkey.git y git checkout use-on-response-started-for-execute .

Hola,
¿Vas a solucionar el problema? Es un defecto bastante antiguo e impacta todos los scripts basados ​​en la estructura de iframes ...

Como recordatorio, mañana tenemos el 13 de marzo (ver Firefox 59.0 ) ...

Quiero referirme a @Sxderp :

webNavigation. Si las opciones incluyesen la clave 'allFrames': true, el problema se resolvería de alguna manera. Cualquier marco en la página html estática tendrá la secuencia de comandos inyectada, aunque luego tendrá problemas de coincidencia de origen / URL. Además, si se crea un marco utilizando Javascript, el script no se inyecta.

En realidad, tengo pruebas de que (en mi sistema) el oyente executeUserscriptOnNavigation se llama de manera confiable con chrome.webNavigation.onCommitted , de modo que chrome.tabs.executeScriptInFrame se llama con el frameId correcto . ¿Por qué esto no resuelve todos nuestros problemas con los marcos? ¡No deberíamos necesitar chrome.webRequest.onResponseStarted para reaccionar en un iframe! (¿O quiso decir, reacciona en el evento, pero el marco no es visible?) Definitivamente se llama ...

¿Existe un error conocido con chrome.tabs.executeScriptInFrame y frameId ? Hubo problemas hace años, pero ahora están solucionados. all_frames no está configurado, por lo que frameId debería ser válido. La opción de configuración matchAboutBlank a true parece importar (de lo contrario, executeScript devolvió un error <unavailable> ), aunque no entendí completamente que about:blank cosas (¿dónde está?) ...

¿Algunas ideas?

¿Características? Esta es la funcionalidad básica que falta desde el principio ... Espero haber malinterpretado eso.

@Eselce , esto fue hace mucho tiempo y no estoy seguro de recordar por completo a qué me refería, pero lo

Ahora, sobre el tema. Cuando hice mi prueba inicial, tenía una página estática con un mismo marco de origen y un marco remoto. En la carga inicial de la página, solo pude hacer que la devolución de llamada onCommitted activara una vez. Se disparó para el documento principal pero no para ninguno de los marcos estáticos del documento [1]. Por lo tanto, no se les inyectaría ningún guión.

Sin embargo, después de la carga inicial, si hice que uno de los marcos 'navegara' en algún lugar, se llamaría a la devolución onCommitted llamada

Se intentó utilizar la tecla de opción all_frames para solucionar el problema anterior. Si bien el uso de la clave hizo que las secuencias de comandos se inyectaran en los marcos de la página, existía el defecto obvio de no hacer coincidir correctamente el origen + ruta del marco con lo que la secuencia de comandos debería o no debería ejecutarse.

Aparte, también mencioné que el uso de la tecla all_frames no inyectaría scripts en los marcos creados por Javascript.

[1] No sé si este problema sigue presente. Si recuerdo, este problema no estaba presente en FF 52 ESR pero sí en 56 (¿57?) (Por lo tanto, regresión). Quizás se haya solucionado.

Estoy de acuerdo contigo en casi todos los puntos.

Y tiene razón en que cada marco se empareja por separado, como si fuera una pestaña completa (con su propio window y su propio document , incrustado en un marco).

Bueno, he usado casi siempre la misma estructura de menú / marco, así que tal vez debería probar una diferente.

Cuando dices "se disparó", ¿te refieres a la pura llamada del oyente?

Como dije, encontré algunos ejemplos en los que executeScript producían una condición de error, pero aún se llamaba al oyente.

all_frames no puede funcionar, debido al location incorrecto (diferente window , diferente document ). Por cierto: el menú solo maneja las URL del mainframe de cada pestaña; si el menú es incorrecto, eso no significa que no se llame al script ...

Cuando dices "se disparó", ¿te refieres a la pura llamada del oyente?

En ese mensaje en particular quise decir 'La función pasada a onCommitted.addListener fue llamada'.

Hola,

Leí esta publicación con atención, pero no entiendo cómo usar su solución alternativa en mi script local ".user.js". ¿Cómo puedo aplicar su solución? Lo siento, soy nuevo.

(Desde la actualización de Firefox, la secuencia de comandos adicional ya no reconoce un iframe emergente generado, pero si abro la misma ventana emergente en una nueva ventana, se aplica la secuencia de comandos).

Gracias de antemano por su ayuda

Ha descrito exactamente cuál es el problema: es como si @noframes estuviera activado. La URL del contenido del marco no activa su secuencia de comandos correctamente. Con suerte, esto se solucionará pronto (abrir marcos en ventanas adicionales es molesto) ...

Gracias Eselce.
Y siempre desde la actualización de Firefox, estoy obligado en el encabezado a declarar todos los scipts '.js' (con require) ya usados ​​en el sitio de destino. (incluido jquerry)
Y no es lo mismo ... Crea errores o conflictos.
¿También conoces este problema?

2945 contiene otro ejemplo para la observación, que los scripts se inician en marcos, pero se abandonan después de algunos milisegundos.

Dudo en dar las URL específicas que estoy probando, ya que están fuera de mi control, pero encuentro un comportamiento consistente pero extraño para transmitir.

Tengo un sitio con el que necesito interactuar. Inicialmente carga un conjunto de marcos / marco con filas = "100%, 0" (un marco para llenar la pantalla) en un dominio diferente. Este cuadro contiene un conjunto de cuadros / 3 cuadros dentro del dominio del conjunto de cuadros / cuadro intermedio.

Algunos de los scripts GM de los fotogramas secundarios 1 + 3 "aparecerán" y luego desaparecerán después del ciclo inicial; nunca volverán después de una operación asincrónica. Eso se ajusta a algún comportamiento descrito en este hilo. Tenga en cuenta que los "blip" y el comportamiento descrito a continuación varían según el navegador / versión de GM, pero no es aleatorio; los patrones son extraños pero 100% repetibles para cualquier configuración dada.

1. El primer conjunto de marcos / marco NUNCA aparecerá. Intenté separar y reconstruir la etiqueta del marco, tanto a través de window.document como unsafeWindow.document, tanto en el ciclo inicial como después de un retraso, pero nada hará que el script GM de ese marco informe algo a console.log. (El @include es *, sin @exclude u otro filtrado de URL).
2. Algunos de los comportamientos posteriores diferirán entre Firefox 52.8 / GM 4.1 y Firefox 60.0 / GM 4.3, pero puedo hacer que los scripts GM de los marcos en cada caso "aparezcan" independientemente de que @noframes esté configurado o no. Esto es con @includes *, sin otros filtros de URL. Estos nunca deberían parpadear con
3. En Firefox 52.8 / GM 4.1, el siguiente conjunto de marcos / 3 marcos SIEMPRE aparecerá. En Firefox 60.0 / GM 4.3, no "parpadean" en la carga del marco inicial.
4. En Firefox 60.0 / GM 4.3, al hacer clic en un enlace en uno de los 3 marcos que navega por otro de los 3 marcos (a través de un atributo "objetivo" en el enlace de anclaje, no un script), aparecerá un "parpadeo", no la nueva URL, sino la antigua URL del marco navegado. (Este es uno de los marcos que parpadearon en la carga inicial en el elemento 3).
5. Aquí está la parte más extraña. En ambas configuraciones de navegador --- Siguiendo los pasos, abrimos la página inicial con 2 capas de conjuntos de marcos, 4 marcos en total y hicimos clic en un enlace en un marco para navegar por un marco diferente en la misma página. Para darle nombre a eso, nuestro conjunto de marcos de segundo nivel mostrado inicialmente tenía marcos "top.htm", "menu.htm" y "start, htm". Hemos hecho clic en un enlace en el marco "menu.htm" para que el marco que sostiene "start.htm" navegue hasta "content.htm", con un comportamiento similar pero ligeramente diferente según la configuración del navegador, como se indicó anteriormente. Ahora, hacemos clic en un enlace dentro del marco "content.htm", para navegar dentro del mismo marco, mismo dominio.

En este punto, la secuencia de comandos para "content.htm" no sólo "parpadeará" ... también permanecerá vivo después de que GM.xmlHttpRequest se haya completado, un evento asincrónico. En este punto, "content.htm" no está en ninguna parte de la pantalla del navegador, pero su secuencia de comandos seguirá funcionando.

Entonces me parece que la razón por la que los scripts de GM en las páginas dentro de los marcos no funcionan es porque el script se carga al descargar la página en lugar de cargar la página. Configurar @ run-at para document-start y poner el script en un evento DOMContentReady de unsafeWindow.document no tuvo ninguna mejora. (Establecerlo en window.document nunca dispara el evento).

-Ryan

En Firefox 52.8 / GM 4.1, el siguiente conjunto de marcos / 3 marcos SIEMPRE aparecerá. En Firefox 60.0 / GM 4.3, no "parpadean" en la carga del marco inicial.

En la transición a Firefox 57, Mozilla cambió _algo_. Sea lo que sea, cambió (o rompió) la forma en que se podían activar los Frames. De esto se habló brevemente en algún otro número. Como resultado, los scripts no se ejecutarían en la carga del marco inicial (57+).

El eventual cambio a userScript o contentScript API debería resolver todo esto de todos modos.

Así que la gente sigue diciendo, sin embargo, Violentmonkey continúa ejecutándose en marcos. VM no separa correctamente los scripts de usuario del contenido de la página web (los CSP bloquean los scripts de usuario, las páginas web pueden reescribir objetos globales, etc.), o habría tirado a Greasemonkey hace mucho tiempo. Quizás estos sean problemas relacionados, pero estoy usando motores de script de usuario, por lo que no tengo que explorar el cromo de Firefox lo suficientemente profundo como para descubrirlo por mi cuenta.

Mmm, este es un tema difícil, algunos de mis scripts ya no funcionan porque no pueden funcionar con iframes. Entonces, parece que no es realmente posible arreglarlo, ¿y tenemos camino para que Mozilla implemente alguna API? ¿No hay nada que podamos hacer nosotros mismos, como una solución temporal? Solo necesito hacer algunas cosas en una página en un iframe, a menudo incluso desde el mismo dominio.

Mi propia solución por el momento es ejecutar Greasemonkey en los marcos superiores y Violentmonkey en los marcos secundarios. No puedo usar Tampermonkey porque tiene una licencia casera ambigua, pero si eso no es un problema para usted, entonces podría funcionar mejor o no.

Tenga en cuenta que VM coloca el script en el propio contexto de la página. Es como la ventana insegura de GM sin el equivalente seguro. Uno de los momentos más memorables que tuve fue la depuración de un script donde el contenido de la página había definido un método 'toJSON () "en Array.prototype, causando que JSON.stringify () escupiera JSON inválido dentro de mi script. Tuve que Atrapar defensivamente y arreglar estos como los encontré.

Otra gran preocupación con VM es que respeta la política de seguridad de contenido de la página de contenido, por lo que cualquier directiva que limite las fuentes del script hará que el script de VM nunca se ejecute. Puede ver esto en la consola del navegador (pero no en la consola web). Es por eso que no puedo ejecutar VM por completo y simplemente deshacerme de GM. Todavía no he encontrado una empresa infantil con un conjunto de CSP, pero cuando lo haga, será completamente inutilizable.

@RyanHanekamp ¡ Gracias por la sugerencia! Entonces, quizás use Violentmonkey para algunos scripts.

¿Violent también tiene algo como GM_getValue sincrónico? Ese es otro problema problemático que rompe muchos scripts en el nuevo Greasemonkey. Sin embargo, todavía confío más en Greasemonkey, por varias razones, así que no lo dejaré.

En cuanto a los iframes, he estado tratando de reemplazarlos con etiquetas de objeto, a las que aparentemente se puede acceder directamente usando Javascript, así:

myObject= document.createElement('object');
myObject.setAttribute('id', 'myObject'); 
document.body.appendChild(myObject);
myObject.setAttribute('src', 'https://example.com');

Luego, una vez que se carga el objeto:
document.querySelector('#myObject').contentDocument.defaultView.document.querySelectorAll('someElementInsideObjectPage')
Al menos esto funciona para mí en un script donde el objeto está en el mismo host que la página principal. También puede enviar mensajes desde y hacia ( ... contentDocument.defaultView.postMessage('hello, object') ) el objeto.

No soy un experto en VM, pero creo que implementa al menos la mayor parte de la API GM_ * original. Sin embargo, creo que es mejor adaptar sus scripts a asincrónico que retroceder a una plataforma sincrónica a largo plazo. Según tengo entendido, Greasemonkey hizo esto como un impulso de rendimiento dentro del nuevo marco Quantum, que no permite llamadas sincrónicas entre scripts de fondo y de contenido.

En cuanto a la solución del objeto, no resolverá mi problema particular, pero me alegro de que otros la hayan encontrado útil. Además de ordenar CSS / properties / etc y hacer que funcione con marcos e iframes, tengo que filtrar los objetos en un proceso de captura como potencialmente inseguros. Hay formas de evitar todos estos problemas, pero VM fue el intermedio más fácil hasta que GM finalmente hace lo que dice en la lata.

Además, si tiene un marco / iframe del mismo origen, también puede acceder al contenido de los mismos directamente. La parte más difícil es el origen cruzado, por lo que necesito scripts de usuario dentro del marco. Configura un canal window.postMessage () para responder a la ventana principal.

@RyanHanekamp Es bueno saber que Violent Monkey todavía tiene el viejo y simple GM_ *. Realmente desearía que Greasemonkey hubiera mantenido el GM_getValue antiguo y sincrónico para compatibilidad con versiones anteriores, además de la nueva versión. Podría intentar implementar la nueva función asincrónica en un nuevo script, pero no soy programador y no estoy seguro de si podría hacerlo funcionar. Y ciertamente no puedo refactorizar el uso del antiguo GM_getValue en un antiguo script de 2000 líneas que encontré en línea ... tantos scripts están rotos ahora.

Entiendo por qué Violent fue la mejor opción para ti. Esperemos que Anthony o Sxderp o alguien más descubra cómo implementar esto eventualmente. Realmente desearía poder contribuir, pero soy un lego total.

Oh, ¿puede acceder directamente al contenido de un iframe del mismo origen (sin postMessage, etc.)? Recuerdo haber pasado mucho tiempo tratando de encontrar una manera, pero no parecía posible. Por eso también cambié a postMessage.

Los marcos y los iframes tienen una propiedad contentWindow que es equivalente a la propiedad de la ventana. Ambos tienen una propiedad de documento para acceder al DOM.

La parte más difícil de trabajar con iframes (en el mismo origen) es detectar cuándo se carga su contenido, porque no puedes hacer sentadillas hasta que eso suceda. onload no funciona como se ve. Firefox proporciona un evento DOMFrameContentLoaded que se activa para CADA fotograma cargado, incluidos los fotogramas de nieto / bisnieto, etc., que puede hacer coincidir con el elemento de marco / iframe original con la propiedad event.target. Si controlas el contenido del marco / iframe, también puedes hacer que responda al padre con postMessage o llamando a un método global en el objeto window.parent.

Hablando de eso ... esa es una posible solución para este problema. Si hay o podría haber una forma de codificar un script de GM para inyectar manualmente un script de usuario en una referencia de ventana de dominio cruzado, el creador del script de usuario necesitaría mucho más codificación, pero podría hacer el trabajo. El patrón sería escuchar DOMFrameContentLoaded, verificar si event.target es de primera generación e inyectar manualmente el script si es así. (Suponiendo que la secuencia de comandos del marco de primera generación puede escuchar DOMContentLoaded para marcos de segunda generación y, por lo tanto, obtener una cadena completa). No habría forma de obtener el comportamiento @ run-at dom-start, y también podría haber problemas de sincronización, pero probablemente podríamos solucionarlos para la mayoría de los casos de uso.

Personalmente, he renunciado a que este problema se haya resuelto y, en cambio, he pasado a codificar directamente una extensión. ¡Que funciona bien en todos los marcos!

La diferencia entre Greasemonkey y Violentmonkey en este punto parece ser que Violentmonkey se activa a partir de scripts de contenido con all_frames establecido en true, mientras que Greasemonkey no tiene scripts de contenido en tiempo de instalación y depende completamente de la dudosa capacidad del script de fondo para olfatear cuando un el marco de la pestaña ha navegado. (Y Violentmonkey falla en las páginas CSP porque inyecta temporalmente una etiqueta SCRIPT en lugar de usar tabs.executeScript (), mucho más seguro).

Ponga un script de contenido estático con all_frames, run_at start, empareja todo para notificar el proceso en segundo plano para start / document.DOMContentLoaded / document.Idle para activar los scripts de usuario para cada run_at, y listo. Una cantidad de trabajo no trivial pero manejable para que este problema desaparezca. Lo arreglaría yo mismo, pero no tengo ningún interés en recorrer sus dependencias de desarrollo y solo podría producir el código de salida.

@RyanHanekamp

y en su lugar pasé a codificar directamente una extensión. ¡Que funciona bien en todos los marcos!

¿Estarías dispuesto a compartir ese código de extensión tuyo?

Mi extensión no es de propósito general. El punto es que al usar un content_script estático en el manifiesto con all_urls, all_frames ejecutará el script cada vez que se cargue o navegue cualquier marco, e incluso puede evaluar el código del constructor de funciones sin importar la política de seguridad de contenido de la página.

No he probado con marcos / ventanas construidos mediante programación, pero me imagino que se ejecutarían en la creación inicial independientemente de la configuración run_at, porque dichos marcos se crean inicialmente en blanco y luego se completan; el motor probablemente solo vería la creación inicial. Tampoco probé data: urls, que pueden requerir una coincidencia explícita; no estoy seguro de si all_urls las cubre, o solo http / https.

Puede que tampoco tenga que ser una referencia estática de content_script, pero parece incierto en la documentación si los scripts de contenido invocados dinámicamente se cargan automáticamente cuando se navega por la página. Mi impresión es que solo se inyectan en pestañas / marcos que coinciden actualmente según el patrón de coincidencia proporcionado, y la navegación no desencadena una reinyección. Pero no veo ninguna desventaja en usar un content_script estático para este propósito.

Greasemonkey obviamente no puede incluir los scripts de usuario como recursos estáticos en el manifiesto, y los scripts de contenido no parecen tener acceso directo a tabs.executeScript (aunque no soy un experto en esto ya que solo llevo unos días), pero lo que PUEDE hacer un script de contenido estático es enviar un mensaje al proceso en segundo plano para hacerle saber que se ha navegado el frameId y a qué URL. Esto sería más confiable que cómo percibo los intentos mencionados en este hilo para enganchar el evento correcto en webRequest o webNavigation. La señal del script content_script estático se convierte en el evento que estamos buscando para activar el cargador / inyector de script de usuario de Greasemonkey.

Posiblemente habría un retraso para los scripts de usuario que estrictamente DEBEN ejecutar_en document_start. La llamada al script en segundo plano es asincrónica y el documento habrá progresado en el momento en que se invoque el script de usuario. Es muy posible que esta sea la razón por la que Violentmonkey usa una etiqueta de secuencia de comandos temporal en lugar de tabs.executeScript, ya que la inyección de la etiqueta de secuencia de comandos se puede realizar directamente desde content_script, sincrónicamente. Me resultaría problemático ser forzado a evitar la incertidumbre del estado del documento para ejecutar_at document_start, pero es preferible que el script no se ejecute en absoluto.

Greasemonkey ... PUEDE [usar un script de contenido estático para] enviar un mensaje al proceso en segundo plano para hacerle saber que se ha navegado el frameId, y a qué URL ...

Esto es lo que solíamos hacer para detectar navegaciones .user.js . Parece una buena y obvia solución: ¡detecta contenido ejecutando un script de contenido!

Pero resulta que CSP puede romper incluso los scripts de contenido de extensión (# 2631 y http://bugzil.la/1267027 y http://bugzil.la/1411641).

Puedo ejecutar mi propio complemento, incluido un constructor de Function () directamente desde content_script, en Firefox 60.0.1 y 52.8.1ESR con el siguiente conjunto de CSP:

datos frame-src :; object-src 'ninguno'; script-src 'ninguno'; datos de style-src 'inseguros-en línea' :; connect-src 'ninguno'; media-src 'ninguno';

2631 se ha cerrado, aparentemente porque Firefox solucionó su error subyacente. El primer bugzilla se refiere a la inyección de etiquetas de script (el método Violentmonkey), no al content_script en sí. El segundo se refiere al atributo sandbox para CSP, lo que no es sorprendente porque obliga al dominio a no completar nunca con éxito una coincidencia de dominio, ni siquiera consigo mismo. Un poco como NaN! == NaN.

Cuando se presentó por primera vez hace varios meses, hicimos las cosas de manera diferente. Hoy usamos webNavigation.onCommitted para detectar la navegación, y en la prueba que estoy ejecutando en este momento, por alguna razón no veo que se active en un marco (ni)).

Hola, ¿esto está resuelto ahora?

No pude conseguir que un script que creé para Tampermonkey se iniciara en un iframe con Greasemonkey.

El código de ejecución no se ha modificado por nuestra parte. Entonces, a menos que Mozilla haya cambiado algo por su parte, esto todavía está roto. Sin embargo, # 2663 debería resolverlo.

Vale la pena señalar que Violentmonkey y Tampermonkey funcionan bien dentro de los marcos incrustados.

Tampermonkey tiene problemas con iframes en Chrome, al menos para mí.

Vale la pena señalar que Violentmonkey y Tampermonkey funcionan bien dentro de los marcos incrustados.

Tampermonkey tiene problemas con iframes en Chrome, al menos para mí.

Pero me funciona en Firefox Violentmonkey. Entonces me pregunto cómo puede funcionar allí.

Me acabo de dar cuenta de que un script que usa la antigua sincronización GM_GetValue también funciona bien en Violentmonkey. ¿Cómo es eso posible? Pensé que Firefox había forzado async GM.GetValue? Estoy tan confundido ahora: presumiblemente Violentmonkey tuvo que sacrificar algo más para seguir admitiendo la sincronización y las otras cosas.

@ Cerberus-tm El cambio en Firefox significó que los datos solo se pueden solicitar desde el almacenamiento de extensión o el contexto de fondo de forma asíncrona (los propios scripts de usuario se envían al script de contenido de forma asincrónica). Sin embargo, los datos podrían proporcionarse a los scripts de usuario de forma sincrónica, si cada script de contenido de GM4 precargó y almacenó en caché en el script de contenido los datos que se almacenan para cada script de usuario que se carga en esa página.

Tal caché permitiría que la secuencia de comandos de contenido respondiera sincrónicamente a las solicitudes de datos de la secuencia de comandos de usuario. La implementación de un caché presenta problemas para mantener la coherencia entre los diversos scripts de contenido, pero eso se puede resolver haciendo que los scripts de contenido escuchen todos los cambios en el almacenamiento de extensiones de GM4. Además, si un script de usuario está almacenando una gran cantidad de datos, almacenarlo en caché en cada script de contenido donde se ejecuta el script de usuario también aumenta significativamente la memoria necesaria para cada script de contenido.

TM y VM eligieron hacer algo similar a lo anterior para no romper la compatibilidad con las API originales de Greasemonkey cuando esos administradores de script de usuario se implementaron para Chrome, que tiene las mismas restricciones wrt. comunicación asincrónica con almacenamiento de extensiones, etc. Dado que ya lo están haciendo para Chrome, no había razón para que cambiaran cuando se implementaron para Firefox.

Entonces, el corte de FF57 a WebExtensions forzó una reescritura de GM, pero no forzó la adopción de las API asíncronas por GM.getValue , GM.setValue , etc. WebExtensions hizo el uso de Las API basadas en asíncronas son más fáciles de implementar que las síncronas, pero no las hicieron necesarias.

Personalmente, creo que la elección y otras opciones para romper la compatibilidad fueron o son desafortunadas. La falta de compatibilidad con versiones anteriores de los scripts que funcionaban bien en GM3 y / o la compatibilidad con TM hace que muchas personas elijan no utilizar GM4. Mi experiencia es que más de 30 de los scripts de usuario que uso, todos los cuales funcionaron bien en GM3, no funcionan con GM4 (o al menos no funcionaron antes de ser reescrito para ser compatibles con GM4). Todavía hay 28 scripts de usuario que uso a diario que funcionan bien en GM3 y no funcionan con GM4.

Publiqué una solución a este problema en Stack Overflow como respuesta a cómo Aplicar un Greasemonkey / ‌Tampermonkey / ‌userscript a un iframe . Básicamente, estoy esperando a que se cargue el marco y luego estoy operando en la matriz window.frames . Utilizo un marcador personalizado en el cuerpo de cada fotograma para indicar que ya he visto el fotograma.

¿Quizás Greasemonkey podría implementar una solución de manera similar?

Sería increíble si también tuviéramos un GM.waitFor(css_selector, action_function) como waitForKeyElements () , pero eso es un aparte.