When does the openWindow promise resolve? #728

aykevl · 2015-07-30T18:32:50Z

I am trying to send a message to a page from a serviceWorker. The goal is to let the page respond to the click (opening what the notification is about).

With this code inside a notificationclick event handler:

clients.openWindow(url).then(function(client) {
    client.postMessage(message);
});

There is a race between delivering the message event and attaching the message event listener (while loading the page). Experimentally, I have found that the only way to receive the event is to add the message event listener before <html>, like so:

<!DOCTYPE html>

<script>
navigator.serviceWorker.addEventListener('message', function (event) {
    console.log('got message:', event.data);
});
</script>

<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
    (...)

This appears very unreliable to me (tested in Chrome for Android version 44 and 45).

A possible solution is letting the promise resolve around the DOMContentLoaded or load events. Another option could be to let the service worker detect when the page is loaded (via an event).

I have used a workaround: sending the needed information in the URL fragment identifier and navigating to the proper URL using history.replaceState in the client (webpage). This works reliable so far.

The text was updated successfully, but these errors were encountered:

jungkees · 2015-08-18T08:23:10Z

Isn't the sync between listener setup and sender's posting a message between different threads rather a general case? I'm not sure whether a snippet below could help? /cc @jakearchibald

// Page
navigator.serviceWorker.addEventListener('message', function (e) {
    console.log('got message:', e.data);
});

document.addEventListener('DOMContentLoaded', e => {
  var controller = navigator.serviceWorker.controller;
  if (controller)
    controller.postMessage('clientloaded');
})

// SW

// Yeah, we need a persistent state to store |client_id|, so assuming that ..

self.addEventListener('notificationclick', e => {
  e.waitUntil(clients.openWindow(url).then(c => { client_id = c.id; }));
});

self.onmessage = e => {
  if (e.data == 'clientloaded') {
    clients.matchAll().then(clients => {
      clients.forEach(c => {
        if (c.id == client_id) {
          c.postMessage('fromnotificationclick');
        }
      });
    });
  }
};

smaug---- · 2015-10-20T13:03:53Z

I think we need some kind of explicit ready() on window side, which would resolve the promise
and probably also implicit ready() at page 'load' event time if the explicit ready() hasn't been used.
The current setup is just way too racy and guaranteed to cause issues on slow networks etc.

jakearchibald · 2015-10-27T08:16:14Z

F2F:

We should buffer messages until startMessages is invoked

Page onload invokes startMessages
Assignment to navigator.serviceWorker.onmessage invokes startMessages
Invocation of navigator.serviceWorker.startMessages() (TODO: bikeshed) invokes startMessages

No change on when openWindow resolves.

smaug---- · 2015-10-27T10:57:42Z

(I'm slightly against making yet another broken onfoo event handler, but I guess since MessagePort already has similarly broken onmessage, doesn't matter too much.)

jakearchibald · 2015-10-28T01:38:30Z

FWIW I didn't know about the onmessage assignment thing and I consider it to be batshit. I'd much rather we just admitted that in some cases listener adding can have side-effects.

jakearchibald · 2016-01-26T21:45:28Z

F2F resolution: startMessages it is.

jakearchibald · 2016-04-10T17:28:01Z

I'd like us to consider allowing addEventListener to also trigger startMessages, then we don't need to expose startMessages.

mkruisselbrink · 2016-04-11T18:25:53Z

If addEventListener triggers startMessages you can't have multiple event listeners anymore. A library setting an event listener will prevent a later (but before document load) added event listener from other code to receive messages that were send before the listener was added.

aykevl · 2016-04-11T20:35:16Z

EDIT: nevermind, this has mostly been suggested before.

Just an idea: triggering startMessages on load or DOMContentLoaded.
This may not be a good solution either: libraries may want to do initialization in DOMContentLoaded and onload may be too late.
Other ideas:

Do startMessages immediately after DOMContentLoaded without exposing startMessages.
Expose startMessages, but do it anyway after onload in case the web app hasn't requested for it specifically.

wanderview · 2016-04-11T21:03:25Z

Gecko bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1263734

wanderview · 2016-04-12T19:47:11Z

We decided to keep the previous f2f decision. Messages are automatically started on DOMContentLoaded, but if you want messages before that you need to call startMessages(). The onmessage assignment also implicitly calls startMessages().

jungkees · 2016-06-14T10:44:15Z

@annevk I'm thinking of defining a task source called client message queue on Window object and WorkerGlobalScope object. Then, client.postMessage() add a task to the client message queue which is consumed by the even loop of those globals when the task source is enabled (like what MessagePort does). Enabling the task source can be done by invoking the start client message algorithm from the three call sites: on DOMContentLoaded (or onload?), onmessage assignment, and navigator.serviceWorker.startMessages().

I was thinking of defining the task source in the service worker client which is a type of environment settings object, but then it can't cover the DOMContentLoaded case.

If the above outline makes sense, I'll make a PR to HTML.

/cc @domenic

annevk · 2016-06-20T08:58:53Z

Sounds reasonable.

A ServiceWorkerContainer object has a client message queue task source, initially disabled, which holds tasks until the client is ready to get the messages from its service worker. This patch adds a condition that enables the task source: - when a document is dispatched a DOMContentLoaded event - when a worker client has executed run a worker algorithm Related Issue: w3c/ServiceWorker#728 Related commit (WIP): w3c/ServiceWorker@c2db88b

jungkees · 2016-07-07T13:10:03Z

I made patches as follows:

SW: c2db88b
HTML: jungkees/html@bca15cf (didn't make a PR yet)

I defined the task source in ServiceWorkerContainer object instead of the global objects. I think it's better since a ServiceWorkerContainer object is the target object at which the message event is dispatched, and we don't pollute the globals. Please review them.

A ServiceWorkerContainer object has a client message queue task source, initially disabled, which holds tasks until the client is ready to get the messages from its service worker. This patch adds a condition that enables the task source: - when a document is dispatched a DOMContentLoaded event - when a worker client has executed run a worker algorithm Related Issue: w3c/ServiceWorker#728 Related commit (WIP): w3c/ServiceWorker@c2db88b

A ServiceWorkerContainer object has a client message queue task source, initially disabled, which holds tasks until the client is ready to get the messages from its service worker. This patch adds a condition that enables the task source: - when a document is dispatched a DOMContentLoaded event - when a worker client has executed run a worker algorithm Related Issue: w3c/ServiceWorker#728 Related commit: w3c/ServiceWorker@5c0ecae

A ServiceWorkerContainer object has a client message queue task source, initially disabled, which holds tasks until the client is ready to get the messages from its service worker. This patch adds a condition that enables the task source: * when DOMContentLoaded is dispatched * when a worker client has executed run a worker algorithm Related issue: w3c/ServiceWorker#728 Related commit: w3c/ServiceWorker@5c0ecae

jungkees · 2016-07-22T08:38:39Z

Addressed by 5c0ecae and whatwg/html@d615947

Closing.

A ServiceWorkerContainer object has a client message queue task source, initially disabled, which holds tasks until the client is ready to get the messages from its service worker. This patch adds a condition that enables the task source: * when DOMContentLoaded is dispatched * when a worker client has executed run a worker algorithm Related issue: w3c/ServiceWorker#728 Related commit: w3c/ServiceWorker@5c0ecae

jakearchibald added this to the Version 1 milestone Oct 28, 2015

jakearchibald mentioned this issue Jan 7, 2016

Create F2F agenda #806

Closed

wanderview added the decided label Apr 12, 2016

jungkees mentioned this issue Jul 8, 2016

Enable the client message queue whatwg/html#1527

Merged

jungkees closed this as completed Jul 22, 2016

jungkees mentioned this issue Jun 27, 2017

consider Client behavior for windows where initial about:blank is replaced with a loaded document #1091

Closed

ytausky mentioned this issue Aug 28, 2018

Enabling client message queue on DOMContentLoaded is not mentioned in the spec #1349

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

When does the openWindow promise resolve? #728

When does the openWindow promise resolve? #728

aykevl commented Jul 30, 2015

jungkees commented Aug 18, 2015

smaug---- commented Oct 20, 2015

jakearchibald commented Oct 27, 2015

smaug---- commented Oct 27, 2015

jakearchibald commented Oct 28, 2015

jakearchibald commented Jan 26, 2016

jakearchibald commented Apr 10, 2016

mkruisselbrink commented Apr 11, 2016

aykevl commented Apr 11, 2016

wanderview commented Apr 11, 2016

wanderview commented Apr 12, 2016

jungkees commented Jun 14, 2016

annevk commented Jun 20, 2016

jungkees commented Jul 7, 2016 •

edited

Loading

jungkees commented Jul 22, 2016

When does the openWindow promise resolve? #728

When does the openWindow promise resolve? #728

Comments

aykevl commented Jul 30, 2015

jungkees commented Aug 18, 2015

smaug---- commented Oct 20, 2015

jakearchibald commented Oct 27, 2015

smaug---- commented Oct 27, 2015

jakearchibald commented Oct 28, 2015

jakearchibald commented Jan 26, 2016

jakearchibald commented Apr 10, 2016

mkruisselbrink commented Apr 11, 2016

aykevl commented Apr 11, 2016

wanderview commented Apr 11, 2016

wanderview commented Apr 12, 2016

jungkees commented Jun 14, 2016

annevk commented Jun 20, 2016

jungkees commented Jul 7, 2016 • edited Loading

jungkees commented Jul 22, 2016

jungkees commented Jul 7, 2016 •

edited

Loading