Web Push notifications not triggered in service worker with e10s

RESOLVED DUPLICATE of bug 1369476

Status

()

Core
DOM: Push Notifications
RESOLVED DUPLICATE of bug 1369476
10 months ago
10 months ago

People

(Reporter: herrernst, Unassigned)

Tracking

(Blocks: 1 bug)

54 Branch
x86
Windows 10
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

10 months ago
Most of the time (but not always), "push" events from web push notifications are not dispatched to a service worker when no corresponding origin window is open and e10s is enabled.

Steps to reproduce:
0. Make sure e10s is on
1. Go to https://framework.realtime.co/demo/web-push/ and allow notifications
1a. Copy the curl command for triggering a push notification
2. Close the page, open some other tabs; maybe browser restart is necessary
3. Enter the curl command; notification should be shown, but isn't

Attached is a screencast for better understanding. First, Firefox runs without e10s because of blocking plugins. Notification is received and shown. Then, plugins get disabled and Firefox restarts with e10s on. Notifications are not shown anymore (Wireshark is running in the background to verify reception of push messages).

We have reproduced it on 32bit and 64bit Windows and also on macOS.
(Reporter)

Updated

10 months ago
Component: General → DOM: Push Notifications
Product: Firefox → Core

Comment 2

10 months ago
We have a known issue on mac where if there are no windows open then we don't handle the push message.  I have not observed this on windows before.

What version of firefox did you observe this on windows?
Blocks: 1226983
Flags: needinfo?(herr.ernst)

Comment 3

10 months ago
I can't reproduce it so far on my windows 10 machine using the steps in comment 0.  I've tried with FF56 nightly and FF54 release so far.
(Reporter)

Comment 4

10 months ago
As entered in the metadata, it's current stable 54.
I've now uploaded the screencast. As noted, the bug doesn't happen every time, but very often.
Flags: needinfo?(herr.ernst)

Comment 5

10 months ago
Ok, I can reproduce now by trying to match the screencast.  It seems that the about:debugging#workers tab seems to cause this to start to happen.

If you close your about:debugging window, does it still reproduce for you?
Flags: needinfo?(herr.ernst)
(Reporter)

Comment 6

10 months ago
It seems to me now that this happens when no "remote content" tab is loaded (excluding "lazy" tabs). If I only have the settings page or new tab page loaded, notifications are not delivered. With the homepage ("about:home"), it still works.
Flags: needinfo?(herr.ernst)

Comment 7

10 months ago
I think this is a known issue.  We currently don't have a way to keep the content process alive without a window open, so we can't spawn the service worker.  I can't find the bug, though.  Catalin, do you remember where we have this filed?

Ultimately we will be fixing this as part of our larger refactor in bug 1231208.
Flags: needinfo?(catalin.badea392)

Comment 8

10 months ago
Sorry, "without a window open" means a "content window open".  Things like about:debugging, etc are not considered content windows and they do not spawn a process.  They run in our parent process instead.
(Reporter)

Comment 9

10 months ago
Ok, thanks for clarifying. So this is probably a minor issue.
There's already a bug for this issue: bug 1369476.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 months ago
Flags: needinfo?(catalin.badea392)
Resolution: --- → DUPLICATE
Duplicate of bug: 1369476
You need to log in before you can comment on or make changes to this bug.