Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(messaging): add config option whether notification should be displayed in the foreground #398

Closed
r0hin opened this issue Jul 5, 2023 Discussed in #397 · 8 comments

Comments

@r0hin
Copy link
Contributor

r0hin commented Jul 5, 2023

Discussed in #397

Originally posted by **r0hin** July 4, 2023 Using Firebase Cloud Messaging, upon receiving notification via FCM token, the notification is shown regardless of whether or not the app is in the foreground.

Is there any existing functionality to disable notifications when the app is open and instead use an in-app notification?

--

Solving this problem without the use of the local notifications and directly within the capacitor-firebase/messaging package would be a cool feature!

@robingenz robingenz changed the title Conditionally show Firebase Messaging notification feat(messaging): add config option whether notification should be displayed in the foreground Jul 5, 2023
@timmyrosen
Copy link

What is the status looking like on this? Would be great if this could be implemented soon. We have a chat app and if two people are chatting at the same time it's pretty annoying to also get a push notification on every message.

Great package otherwise, thanks for all the hard work!

@robingenz
Copy link
Member

@timmyrosen This PR is intended to ensure that you also receive push notifications on Android in the foreground. I think you are looking for the opposite (probably for iOS).

@tomek-em
Copy link

tomek-em commented Sep 11, 2024

That's what I am looking for. Any way to disable notifications when the app is in foreground on iOS.

@robingenz
Copy link
Member

@tomek-em Got it!

What is the status looking like on this?

PRs are welcome!

@travisBradfield
Copy link

Following.

@robingenz
Copy link
Member

robingenz commented Feb 19, 2025

I've just noticed that it's already possible to configure whether a notification should be shown if the app is in the foreground on iOS using the presentationOptions configuration option. You just have to set an empty array:

{
  "plugins": {
    "FirebaseMessaging": {
      "presentationOptions": []
    }
  }
}

I'm therefore closing this issue.

@egemadra
Copy link

This was previously asked here

@robingenz I'm not sure if this is the right place to ask. But is it also intended that the requestPermission() will automatically return 'denied' when you have no presentationOptions configured? I would still like to show the permission prompt even when I don't show the notifications in the foreground.

And you replied:

@roosalyn Yes, this is intended. If no presentation options are defined, you do not need any permissions. If you have more questions, please create a discussion.

"presentationOptions": [] is effectively unusable in such case, because with that setting we get no notifications, be it background or foreground. The documentation is misleading as its behavior is to immediately deny the request just as you stated in the other thread. What is really needed is the behavior in the documentation. So effectively an empty array should result in no action in the app when it is in the foreground, and the requests for permission should not be automatically rejected with "denied", but the app should ask the user for the permission instead. If user gives permission, that should mean the app could get notifications in the background only as defined in apns.payload.aps key in the message body.

As a side note, I think the empty array option was working as intended (conforming to the documentation) about 2 years ago, if I remember correctly. The behavior of immediate denial must have been added sometime later. I wrote this with the hope that it could help track the issue somewhere in commit history.

@robingenz
Copy link
Member

@egemadra Yes, you're right. Seems like this PR has broken it: 2085bb8. This will be fixed in the next release, see #826.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants