¿Los trabajadores web compartidos persisten en una sola recarga de página, navegación de enlaces?

StackOverflow https://stackoverflow.com/questions/9336774

Pregunta

Shared Web Workers están diseñados para permitir múltiples páginas desdeel mismo sitio (origen) para compartir un solo Web Worker.

Sin embargo, las especificaciones (u otros tutoriales e información sobre trabajadores compartidos no me dejan claro) si el trabajador compartido persistirá si solo tiene una ventana / pestaña del sitio y navega a otra página del mismo sitio.

Esto sería más útil en el caso de una conexión WebSocket desde el Trabajador compartido que permanece conectado mientras se navega por el sitio.Por ejemplo, imagine un indicador de cotización o un área de chat que persistiría (sin tener que volver a conectar el WebSocket) incluso mientras se navega por el sitio.

¿Fue útil?

Solución

He realizado algunas pruebas para encontrar la respuesta a esto en la práctica.

Firefox aún no admite la creación de conexiones WebSocket desde Web Workers: https:// bugzilla. mozilla.org/show_bug.cgi?id=504553 Entonces, Firefox no es relevante hasta que se resuelva ese error.

IE 10 no tiene soporte para trabajadores web compartidos , por lo que tampoco es relevante. Eso deja a Chrome.

A continuación, se muestra un ejemplo para probar los trabajadores web compartidos.

Primero el HTML: 

<!DOCTYPE html>
<html>
<body>
    <a href="shared.html">reload page</a>
    <script>
        var worker = new SharedWorker("shared.js");
        worker.port.addEventListener("message", function(e) {
            console.log("Got message: " + e.data);
        }, false);
        worker.port.start();
        worker.port.postMessage("start");
    </script>
</body>
</html>

Luego, la implementación del propio trabajador compartido en shared.js: 

var connections = 0;

self.addEventListener("connect", function(e) {
    var port = e.ports[0];
    connections ++;
    port.addEventListener("message", function(e) {
        if (e.data === "start") {
            var ws = new WebSocket("ws://localhost:6080");
            port.postMessage("started connection: " + connections);
        }
    }, false);
    port.start();
}, false);

Resultados de la prueba en Chrome 20 ( la respuesta ):

Cuando la página se carga simultáneamente en dos pestañas independientes, el recuento de conexiones aumenta cada vez que se vuelve a cargar una de las páginas o se hace clic en el enlace autorreferencial.

Si solo se carga una instancia única de la página, el recuento de conexiones nunca cambia cuando se vuelve a cargar la página o se hace clic en el enlace.

Por lo tanto, en Chrome 20: Los trabajadores web compartidos no persisten en las recargas de página y los clics de navegación de vínculos .

Otros consejos

Parece que este es básicamente el mismo problema que la pregunta '¿Qué le sucede a un hilo de trabajo web HTML5 cuando la pestaña se cierra mientras se está ejecutando?' . Creo que la parte clave de la especificación es esta declaración :

Los agentes de usuario pueden invocar el modelo de procesamiento "matar a un trabajador" en un trabajador en cualquier momento, p. ej. en respuesta a las solicitudes de los usuarios, en respuesta a Gestión de cuotas de CPU, o cuando un trabajador deja de ser un activo necesario trabajador si el trabajador continúa ejecutando incluso después de su bandera de cierre se estableció en verdadero.

Un ' activo trabajador necesario 'se define de la siguiente manera:

Se dice que un trabajador es un trabajador activo necesario si alguno de los documentos los objetos en los documentos del trabajador están completamente activos.

Entonces, según tengo entendido, si todas las ventanas que hacen referencia a un trabajador están cerradas, la especificación requiere que el navegador termine el trabajador, pero no de inmediato. Dependiendo de que persista, por lo tanto, no será confiable incluso si parece funcionar ocasionalmente.

En su ejemplo, mi enfoque sería cargar todo el sitio mediante Ajax; no podrá ejecutar Web Workers si sus usuarios tienen JS deshabilitado de todos modos, luego use API de historial para que la dirección de la página del usuario se corresponda con la página real (manteniendo la compatibilidad con motores de búsqueda y no JS).

He tenido éxito con una técnica algo indirecta mediante la cual cuando quiero ir a la página siguiente pero mantener SharedWorker, abro una ventana emergente (con suerte, no intrusiva) que crea el mismo trabajador, espero a que se active yenviar un mensaje al puerto / ventana original, que luego navega a la nueva página y luego, cuando esa página se carga, cierra la ventana emergente.Esta estrategia mantiene al menos una conexión activa en todo momento, por lo que el trabajador nunca decide cerrar.

Esta técnica parece ser bastante sólida hasta ahora.Aunque ver la ventana emergente es algo molesto, es un compromiso razonable para algunos casos de uso.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top