28

Update: Google Bug Report Description

(as suggested by google dev advocate in comments on answer 1, filed a bug report; updating the content here since it more succinctly and precisely describes the problem)

I do not need or want to show any notifications to my user. And many users are not willing to give notifications permission because they assume they will start seeing notifications.

But I wish to push data to my web page from the server. The web page is active and in the foreground. This is the classic use case that Web Sockets were designed for.

I understand that I could write my own web socket server and somehow try to scale it, or go to some other third-party for an outsourced scalable web socket push solution.

But, isn't this is a very common "sub-use-case" of the messaging that Firebase Messaging is targeted towards? Therefore shouldn't Google support this use case? I can't see any fundamental technical show-stoppers, but since Google is so smart, please do enlighten me if I am missing something on why this cannot or should not be done.

Original StackOverflow Question Text:

I don't need background notifications or service workers. All I want is to send data to the web page when it is currently loaded and in the foreground.

Websockets do not need any permission but they need a websocket server and maintenance. It is difficult or expensive to scale it.

Firebase solves the problem fundamentally but I don't see why it must require a user to give notifications permission even though I only want to push data when the page is loaded; not in the background.

user2297550
  • 3,142
  • 3
  • 28
  • 39
  • 1
    I'm facing the same issue, what solution did you end up using? – Jason Mar 25 '19 at 01:06
  • The expensive solution is to use Cloud Firestore notifications (long-polling, web sockets) instead of the Push API, when app is in foreground. The root cause seems to be that the powers-that-be want to kill web apps in favor of mobile apps, so the Push API spec requires one to get "show notification permissions" from the user even if one will never show a notification and merely receive async notifications. – user2297550 Mar 25 '19 at 04:42
  • Do you know any code example of this? Would you be willing to help me further if you have experience in this. – Jason Mar 25 '19 at 12:18
  • @Jason See the first "Web" code section at https://cloud.google.com/firestore/docs/query-data/listen In this scheme you would create a table with columns: uid, sequence, message. Then you listen to the doc(uid) and as the message is updated on the server the client will get real-time updates. Once you digest this and feel it is in the ballpark for your needs then read further below: https://cloud.google.com/firestore/docs/query-data/listen#listen_to_multiple_documents_in_a_collection – user2297550 Mar 25 '19 at 12:40
  • Ok thanks, so the other component is how do I get the FCM data messages into that table? My current cloud solution was only to send registrationIds via https://fcm.googleapis.com/fcm/send and it didn't require any tables. I would be willing to pay for your time for more guidance, you could reach me here https://jasonsavard.com/contact – Jason Mar 25 '19 at 13:17
  • @Jason need to add/modify firestore database on server-side, in python e.g.: `import firebase_admin; firebase_admin.firestore.client().collection('foo').doc('someuid').set({'xyz': 'abc'})` or something like that; i'll probably be too expensive to hire ad hoc so get the free help while you can ;-) sending an email anyway to keep in touch. (will also need a `firebase_admin.initialize_app(firebase_admin.credentials.Certificate('someprojectcredentialsjsonfile.json'))` before hitting the database) – user2297550 Mar 25 '19 at 15:52
  • 2
    Can you please link to this bug report for us to upvote? – D2TheC Apr 20 '21 at 10:25
  • @D2TheC Here is the subject line from my email that acknowledge the issue: Re: [8-6454000024239] Web App - Cannot Replace WebSockets Use Case but for the life of my I cannot find an issue tracker for firebase where this could be viewed/monitored/upvoted. Can you find it using the id? – user2297550 Apr 20 '21 at 12:38
  • 1
    @D2TheC also, apparently a google firebase team member has answered this question below (doug stevens), and one way to raise their attention would be to add a comment to his answer and see if they are amenable to persuasion. – user2297550 Apr 20 '21 at 12:42

2 Answers2

17

The problem is that Firebase Messaging is only using 1 method to deliver notifications. That is the Push API specification spec, and that specification (wrongly and unfortunately) does not allow a service worker to receive messages without the user allowing an unrelated permission to show notifications.

The fix would be for the Firebase Messaging team to provide a different way to deliver messages to active web pages -- long polling, or websockets.

But it would be extra work for them, and may be not enough people are requesting it.

user2297550
  • 3,142
  • 3
  • 28
  • 39
2

It's to protect the user's preferences about what your app is allowed to do. The way push messaging works on browsers is by using a service worker. Even though you say you don't need a service worker, you are actually making using of it when using Firebase Cloud Messaging in your app.

Given that, the prompt is necessary because the browser doesn't know what you intend to do with that push message. If the user doesn't trust your app, they should have the right to limit what it can actually do, especially when they're not using your app. Mobile operating systems (iOS, Android) are the same way.

Doug Stevenson
  • 297,357
  • 32
  • 422
  • 441
  • 1
    It seems the notifications permission should come into play only when my code tries to show a notification. If a service worker consumes messages without doing anything with them that should not require notifications permission. – user2297550 Nov 21 '18 at 01:23
  • 1
    Feel free to file a bug report if you think it's doing the wrong thing. http://firebase.google.com/support/contact/bugs-features – Doug Stevenson Nov 21 '18 at 01:40
  • 2
    Didn't realize you were a developer advocate. I filed a report as you suggested and updated the question text with a more precise description of the problem. Could you please let me know that at least you understand the problem (in my revised, precise description). I'd appreciate it if you could get one of the engineers to sound off on this. The key is that I need push but I don't need to show notifications, and many users disallow notifications permissions because they reasonably expect to start seeing notifications, which I do not need to show. – user2297550 Nov 21 '18 at 03:28
  • 1
    Yes, that's what I'm hoping will happen from your contact with support. – Doug Stevenson Nov 21 '18 at 03:31
  • thx -- ignore this since I may be overstaing the point. Also, to further respond to your answer -- starting a service worker to receive messages has nothing to do technically with showing notifications. I could receive messages and the only action would be to either communicate with the web page code if it is active, or do nothing. User-visible notifications are **orthogonal**/independent of receiving messages. Right? – user2297550 Nov 21 '18 at 03:31
  • 1
    I'm guessing the browser's logic is that if you intend to receive push messages, it assumes that you *may* also attempt to show a visible notification, but it can't know for sure, so it just covers the base. – Doug Stevenson Nov 21 '18 at 03:32
  • (Thanks for your assistance.) Yes, that's very likely the case. My point is that "covering the base" has the downside of a significant fraction of users simply disallowing push to active web pages. I'm sure it affects a large user base other than me. If you are like me you probably too routinely click "no" when exploring a new website that immediately asks to show notifications the first time you visit it. – user2297550 Nov 21 '18 at 03:38
  • 2
    One option is to use Firebase Real-time Database or Cloud Firestore as the message delivery system. Since you don't need background messaging just write to the database and your foregrounded app will get the update. – Arthur Thompson Nov 21 '18 at 04:29
  • 2
    @ArthurThompson Thank you. I successfully coded the solution you suggested and I am able to use Cloud Firestore as a message delivery system, without asking miy users to give the unnecessary "Show Notifications" permission. The problem is that Firestore is very expensive relative to messaging because it is really a super-smart database first and foremost. – user2297550 Nov 25 '18 at 08:33
  • @DougStevenson please see my answer/suggestion again (above) after a lot of water has flowed under the proverbial bridge. The feature request went nowhere as expected. As I diagnosed earlier, there are other ways besides the Push API to deliver real-time updates, that do not require granting special permissions. Perhaps the team could consider offering them (simple websockets, or even long-polling) – user2297550 Apr 20 '21 at 12:41
  • @DougStevenson notifications to the application and notifications to the user should be two different things. Other services such as Azure SignalR (without sockets) and Azure Service Bus are able to offer this functionality – D2TheC Apr 20 '21 at 12:51