Service worker unable to communicate with the HTTPS iFrame on Firefox

[jasonpang]

Our service worker communicates with the HTTPS iFrame to support events like "a notification has been displayed" and "a notification has been clicked". Technically, how this works is:

• The service worker calls self.clients.matchAll({type: 'window'}) to get all clients (pages) the service worker controls. On Chrome, this includes nested frames (although Chrome may remove support for this in the future, bug is possibly hidden due to security issue? not sure). On Firefox, the call does not seem to include nested frames (firefox may also remove support for this). It currently isn't clear why this call on Firefox is returning an empty array of window clients due to errors not being correctly displayed in the service worker Firefox dev tools console.
• A third-party library (swivel) run on both the service worker and host page communicate with each other through some combination of MessagePort/ postMessage / a message event listener.

On Chrome, all this works okay. On Firefox, due to the nested HTTPS frame not being included in self.clients.matchAll(), it isn't possible for the Firefox service worker to communicate with the nested HTTPS iframe.

This bug:

• Prevents the host page from receiving the notificationDisplay event
• Prevents the host page from receiving the notification click event

[jasonpang]

Asked the Mozilla guys for more info @ https://bugzilla.mozilla.org/show_bug.cgi?id=1286417

[jasonpang]

Looks like Firefox's behavior is now spec-complaint, so this feature will intentionally not work in Firefox and may even be removed from Chrome.

[jasonpang]

In Chrome 52+, the ServiceWorker method Clients.matchAll() no longer returns HTTPS iframes nested under an HTTP page, since this is an insecure context. Firefox 47.0.1 also no longer returns HTTPS iframes nested under an HTTP page using Clients.matchAll().

Fortunately, in Chrome, using the option {includeUncontrolled: true} returns us the HTTPS iframe, so we can use it to send a message from the service worker to the client.

In Firefox, this option does not return us the HTTPS iframe. Chrome is actually deviating from the spec (2.2.1):

If client is not a secure context, continue to the next iteration of the loop.

According to this, Chrome's {includeUncontrolled: true} should not be working (but it does). We'll probably expect Chrome to fix this behavior in the future, which would mean our service worker cannot communicate with the page anymore.

[jasonpang]

For any web push users stumbling on this issue, the best "solution" for now is to transition your site to HTTPS if possible!

[prashantagarwal]

@jasonpang Can we communicate to serviceworker through this hidden https iframe ?

[jasonpang]

Hi @prashantagarwal,

In the most recent versions of Chrome, inside of the HTTPS iFrame, navigator.serviceWorker.ready, navigator.serviceWorker.getRegistration(), navigator.serviceWorker.getRegistrations() all return DOMException: Only secure origins are allowed. This means the HTTPS iFrame is unable to initiate communications with the service worker. However, the HTTPS iFrame is still able to install a message event listener to receive messages from the service worker (via the navigator.serviceWorker.onmessage event listener). On the other side, the service worker is able to use clients.matchAll({includeUncontrolled: true}) to obtain a reference to this HTTPS iFrame and postMessage to it; the HTTPS iframe, upon receiving this message, is able to reply back because the event provides a reference to the service worker to reply. So the HTTPS iFrame isn't able to initiate communication with the service worker; it can only listen for messages and reply. The service worker is able to send messages to the HTTPS iFrame. This case is good enough for what we need to do.

[jasonpang]

For some reason, in Firefox, clients.matchAll() even without includeUncontrolled seems to return the HTTPS iframe under an HTTP webpage (in other words Firefox has just as full featured support as Chrome now for our SW notification events). I thought this wasn't supposed to happen, and I don't think this happened when I was first testing this out, but this is good for us!

Here it is working on Firefox 48.0.1:

[jasonpang]

Now that this works again, closing the issue.

[jasonpang]

Part of this issue seems to be open again: https://app.intercom.com/a/apps/344a89aeac3f033e4dec4370781543b948aece6d/inbox/jason@onesignal.com/conversations/5117244924.

[jwilm]

Closing this until we hear another report as the previous is a year old

[vgalisson]

Hi @jasonpang I'm using OneSignal as the java webapp I'm working on is not fully HTTPS yet. I managed to make it work by putting the javascript directly into the jsp but now that I moved this code outside in a js file, I encountered what I think is related to this specific issue.

From the debug log I get from the OneSignal SDK, it tries to open an iFrame to https://my-app-name.onesignal.com/webPushIframe but is not able to and times out.
OneSignalSDK.js gives a SecurityError: The operation is insecure.
(In addition, in the iFrame, OneSignal is not defined and thus the SDK throws a ReferenceError)

Do you know if the compatibility changed for newer versions of Firefox (i'm using version 60) ? And if so, is there any workaround ?

Thanks in advance !