React-native: PushNotificationIOS.requestPermissions promise never resolves

[chandlervdw]

I'm confused as to how this is supposed to be used. The RN PushNotificationIOS docs say:

This method returns a promise that will resolve when the user accepts, rejects, or if the permissions were previously rejected. The promise resolves to the current state of the permission.

But when I use the following, console.log() is never hit.

PushNotificationIOS.requestPermissions().then((permissions) => console.log(permissions));

What am I missing?

[nazywamsiepawel]

+1, I'm facing the same issue

[upgle]

plz check it #8622

[mikelovesrobots]

+1

I thought I was missing something really obvious. Glad I'm not.

[ambarc]

+1 only in the user rejects permissions case. On RN 0.32 I get something like {"alert":1, "sound": 1, "badge": 1} as the response argument on success when the user provides permissions. Nothing when the user rejects.

[joshuapinter]

Same here. The commit that added the promise for requestPermissions() has been in there since 0.28 but I've never had it working. Now trying on 0.33.0 and it's still not working.

[joshuapinter]

Figured out something very strange...

In order for PushNotificationIOS.requestPermissions() to resolve the Promise, you _need_ to add an event listener, like this:

PushNotificationIOS.addEventListener('register', (token) => {});

What's even more interesting is that it doesn't even have to be the 'register' event, it could be 'notification' or 'localNotification' and it will still cause the promise to resolve.

So this is what I ended up using anywhere I use requestPermissions() and needed to handle the promise:

componentWillMount() {
  // NOTE: You absolutely need this for requestPermissions() promise to resolve.   
  PushNotificationIOS.addEventListener('register', (token) => {});
}

componentWillUnmount() {
  PushNotificationIOS.removeEventListener('register', (token) => {});
}

Can at least a couple of you test this and confirm the behaviour. Once it's reproducible on more than just my machine, I'll see what's the cause and issue a PR to fix it.

Thanks.

[superandrew213]

#8622 fixes this

[joshuapinter]

@superandrew213 Are you sure, because they seem to be related, but different issues. That issue seems to be regarding calling requestPermissions() a second time before the first call has been resolved.

[onpaws]

Today I included
PushNotificationIOS.requestPermissions().then((perms) => console.log(perms));
on app startup and I got the standard iOS permissions prompt as expected.
Seems like maybe RN 0.33 included whatever was needed to fix?

RN 0.33, OS X 10.11.6, iOS Simulator on 9.3

[joshuapinter]

@onpaws Try denying permission and running this again to see if you get the promise resolved.

[onpaws]

@joshuapinter ah, gotcha.
I was able to repro; denying perms and running app again never resolves promise.
As a stopgap the fix also works on my end, e.g.

PushNotificationIOS.addEventListener('register', (token) => {});
PushNotificationIOS.requestPermissions().then((perms) => console.log(perms));

[joshuapinter]

Thanks for confirming, @onpaws!

[krishangupta]

@joshuapinter's solution works perfectly for me. Thanks!

[joshuapinter]

Thanks for also confirming, @krishangupta!

I'll wait to hear from a React Native core team member before I write the PR as those take a long time to write and get approved so I'd like their alignment on this issue.

[abazlinton]

PR #13263 should resolve this I think

[joshuapinter]

@abazlinton Sweet, let's hope it gets into 0.44.

[ggaabe]

@joshuapinter your fix didn't work for me. I put the register function in the constructor, the componentWillMount, and in the constructor and componentWillMount of a child component that can also call the requestPermissions function if the user decides to turn on notifications inside of that.

The promise still doesn't resolve though, as I still get the "cannot call requestpermissions twice before the first has returned" if I try to request permissions from the child component. (requestPermissions is initially called inside the constructor of the parent).

Any ideas?

[hramos]

Hi there! This issue is being closed because it has been inactive for a while. Maybe the issue has been fixed in a recent release, or perhaps it is not affecting a lot of people. Either way, we're automatically closing issues after a period of inactivity. Please do not take it personally!

If you think this issue should definitely remain open, please let us know. The following information is helpful when it comes to determining if the issue should be re-opened:

• Does the issue still reproduce on the latest release candidate? Post a comment with the version you tested.
• If so, is there any information missing from the bug report? Post a comment with all the information required by the issue template.
• Is there a pull request that addresses this issue? Post a comment with the PR number so we can follow up.

If you would like to work on a patch to fix the issue, contributions are very welcome! Read through the contribution guide, and feel free to hop into #react-native if you need help planning your contribution.

[onpaws]

@joshuapinter would you happen to know if this has been resolved?

[joshuapinter]

@onpaws I don't think so but I haven't tested it in a long time. Let me know if you try it out or not. Might be a good reason to upgrade to the latest React Native version.

[Rested]

Still getting this problem on 0.50.0

[onpaws]

Haven't tried this in a while but a shame to hear that it's still an issue.

@Rested not sure the protocol FB expects here, but if it's an issue you're facing maybe you can re-open this?

[remigallego]

Still happening on 0.55.1 😞