how should push notifications work for standalone web apps?

NEW
Unassigned

Status

()

defect
P5
normal
2 years ago
9 months ago

People

(Reporter: sorin.davidoi, Unassigned, NeedInfo)

Tracking

(Blocks 2 bugs)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(fennec+, firefox58 affected)

Details

(Whiteboard: [pwa-front-end])

(Reporter)

Description

2 years ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20171024100135

Steps to reproduce:

- Go to https://tests.peter.sh/notification-generator/
- Add to Home Screen
- Close tab and open the web app from the home screen
- Set action to "Only open a new window"
- Click "Display the notification"
- Close the web app and Firefox (dismiss them from the recent apps)
- Click on the push notification notification


Actual results:

Firefox opened a new tab with the website.


Expected results:

Firefox opens the web app.
I think there are some questions about how all this should work.

The way a push notification works is:

1. Service worker gets a push event.
2. Service worker calls an API to show the notification.
3. User clicks the notification.
4. Service worker gets a notificationclick event.

At this point service workers often do 1 of 2 things:

1. Try to find an existing window and focus it with Clients.matchAll() and Client.focus().
2. Open a new window with Clients.openWindow().

If Clients.matchAll() returns the standalone Client, then focus will bring the "app" to the foreground.  It can also, however, find tabs opened in the browser for the same origin.  In those cases it will focus the tab instead.

For Clients.openWindow() we have no hint about whether the window should be opened in the browser or as a standalone window.  It functions exactly like window.open(), etc.

Also, I think there are some UX questions here.  For example, if the standalone app is already open and we want to openWindow() in the standalone app, what should happen?  AFAIK standalone doesn't have the concept of "tabs".

In firefox OS we used to create a separate "cookie jar" for "installed" apps.  That made the standalone app have its own origin so everything just went to the app automatically.  I believe google's webapk may have a similar effect.  We had lots of problems in firefox os around web usability with this approach though.  Users didn't understand why they had to log into services separately on every single standalone window.  Its unclear if we should do something like this here.  (I personally think we should not.)

Anyway, we should have a designer look at this use case and decide how we want it to work.  We can then investigate what that means for service workers and the platform.

Andreas, is anyone looking at this currently?
Flags: needinfo?(abovens)
Summary: Push notifications open browser, not web app → how should push notifications work for standalone web apps?
(Reporter)

Comment 2

2 years ago
> If Clients.matchAll() returns the standalone Client, then focus will bring the "app" to the foreground.  It can also, however, find tabs opened in the browser for the same origin.  In those cases it will focus the tab instead.

This makes perfect sense to me.

> For Clients.openWindow() we have no hint about whether the window should be opened in the browser or as a standalone window.  It functions exactly like window.open(), etc.

I would argue that if the user added the app to the home screen, we should bring that up instead of the full-browser UI. The user made an explicit action (adding to the home screen), so it makes sense to me to respect that.

> For example, if the standalone app is already open and we want to openWindow() in the standalone app, what should happen?  AFAIK standalone doesn't have the concept of "tabs".

I say that in this case the full browser UI should be used. The developer had the chance to focus an exisiting tab but they explicitly wanted a new "window".

Updated

2 years ago
Status: UNCONFIRMED → NEW
tracking-fennec: --- → ?
Ever confirmed: true
Marcos, is there anything in the manifest which explicitly hints as to whether new windows for the matching scope should always be opened in standalone mode?
Flags: needinfo?(mcaceres)
Hi Mark,

Was speaking with snorp and we believe its worthwhile to investigate the PWA notification user flow. Not for 58, but for 59, this would be a good bug to tackle. Please consult abovens as he has some ideas around this.
Flags: needinfo?(mliang)

Comment 5

2 years ago
Discussed with the team here. We expect to take quite some time to tackle it from design to implement, and don't think we should stop PWA of 58 due to this, so set P2.

Current action will be on Mark to investigate the design (and discuss with Andreas).
Priority: -- → P2

Updated

2 years ago
Whiteboard: [pwa-front-end]
> Marcos, is there anything in the manifest which 
> explicitly hints as to whether new windows for the matching 
> scope should always be opened in standalone mode?

No. We would need to enhance window.open() or something.
Flags: needinfo?(mcaceres)
(In reply to Nicole Yee (:nicoleyee) from comment #4)
> Hi Mark,
> 
> Was speaking with snorp and we believe its worthwhile to investigate the PWA
> notification user flow. Not for 58, but for 59, this would be a good bug to
> tackle. Please consult abovens as he has some ideas around this.

Yes I will have a discussion with abovens and joe to think about the different cases.

Updated

2 years ago
tracking-fennec: ? → +
Chrome solves this using WebAPKs, which we don't support at this point, so we'd have to find our own solution. 

It's my understanding that one of the challenges is that we don't really "know" if a website has been added to the home screen, unless the OS is Android N or O, which has an API to query home screen shortcuts. @snorp has some insights here, I believe.

@mark_liang, happy to discuss this further.
Flags: needinfo?(abovens) → needinfo?(snorp)
What if website A send out a push notification to open website B, and website B happens to have a web app install on the device?
I think using the browser app is better for this scenario. 
Suggest to keep it as is.
This does need some thought, but I don't think anyone has bandwidth for it currently.
Flags: needinfo?(snorp)
Re-triaging per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195

Needinfo :susheel if you think this bug should be re-triaged.
Priority: P2 → P5
You need to log in before you can comment on or make changes to this bug.