Подтвердить что ты не робот

Работают ли общие веб-работники в одной перезагрузке страницы, навигации по ссылкам

Общие веб-работники предназначены для того, чтобы несколько страниц с одного и того же сайта (источника) могли совместно использовать одного веб-рабочего.

Однако мне не ясно, из спецификации (или других учебных пособий и информации об общих рабочих), сохраняется ли общий рабочий, если у вас есть только одно окно/вкладка с сайта, и вы переходите на другую страницу на том же сайте.

Это было бы наиболее полезно в случае соединения WebSocket от общего рабочего, которое остается подключенным при навигации по сайту. Например, представьте себе запасной тикер или область чата, которая будет сохраняться (без повторного подключения к WebSocket) даже во время навигации по сайту.

4b9b3361

Ответ 1

Я провел некоторое тестирование, чтобы найти ответ на это на практике.

Firefox еще не поддерживает создание соединений WebSocket от веб-рабочих: https://bugzilla.mozilla.org/show_bug.cgi?id=504553 Таким образом, Firefox не имеет значения до тех пор, пока эта ошибка не будет решена.

IE 10 не поддерживает поддержку для общих веб-работников, поэтому это не имеет отношения. Так что Chrome.

Вот пример тестирования общих веб-работников.

Сначала 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>

Затем реализация самого совместно используемого работника в 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);

Результаты тестов в Chrome 20 (ответ):

Когда страница загружается одновременно на двух отдельных вкладках, счетчик подключений растет каждый раз, когда одна из страниц перезагружается или нажимается ссылка на самореференцию.

Если загружен только один экземпляр страницы, то счет подключения никогда не изменяется при перезагрузке страницы или нажатии ссылки.

Итак, в Chrome 20: Общие веб-работники не сохраняются при перезагрузке страниц и не привязаны к ссылкам навигации.

Ответ 2

Кажется, что это в основном та же проблема, что и вопрос "Что происходит с потоком веб-рабочего HTML5, когда вкладка закрыта во время ее работы?" . Я думаю, что ключевая часть спецификации это утверждение:

Пользовательские агенты могут ссылаться на модель обработки "убить рабочего" на работника в любое время, например. в ответ на запросы пользователей, в ответ на Управление квотами ЦП или когда рабочий перестает быть активным если работник продолжает выполнение даже после его закрытия было установлено значение true.

An 'активный необходимый работник' определяется следующим образом:

Работник считается активным рабочим, если какой-либо из документов объекты в рабочем документе Документы полностью активны.

Итак, как я понимаю, если все окна, ссылающиеся на рабочего, закрыты, то браузер требует от браузера прекратить работу, но не сразу. Поэтому в зависимости от этого сохраняющаяся будет ненадежной, даже если она работает иногда.

В вашем примере мой подход состоял бы в том, чтобы загрузить весь сайт Ajax - вы не сможете запускать веб-работников, если у вас есть JS-отключенный, а затем используйте API истории, чтобы адрес страницы пользователя соответствовал фактической странице (поддерживая поисковую систему и совместимость с JS).

Ответ 3

У меня был успех с несколько обходным методом, когда я хочу перейти на следующую страницу, но поддерживаю SharedWorker, я открываю всплывающее окно (надеюсь, ненавязчивое), которое создает одного и того же работника, дожидаясь его активации и отправьте сообщение в исходный порт/окно, которое затем переходит на новую страницу, а затем, когда эта страница загружается, закрывает всплывающее окно. Эта стратегия поддерживает как минимум одно активное соединение в любое время, поэтому рабочий никогда не решает закрыть.

Этот метод кажется довольно надежным до сих пор. Хотя просмотр всплывающего окна несколько раздражает, это разумный компромисс для некоторых случаев использования.