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
fix: reply notifs sometimes destroyed too early #25086
Conversation
2fc675f
to
1d25210
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if the user never clicks reply? will the notif live forever?
@nornagon same behavior as a non-reply notification which is not directly interacted with - it disappears from view on its own. |
1d25210
to
1609a7d
Compare
7cc50ae
to
c1770ef
Compare
Release Notes Persisted
|
I have automatically backported this PR to "10-x-y", please check out #25100 |
I have automatically backported this PR to "9-x-y", please check out #25101 |
I have automatically backported this PR to "8-x-y", please check out #25102 |
This reverts commit bea6c9e.
Description of Change
Closes #25062.
Fixes an issue where notifications with a reply button could potentially be destroyed too early when a user clicked on the notification body before replying, which meant that when they did finally reply the reply callback would never be called. This happened because we were destroying the notification on any activation type, and it's possible for reply-type notifications to be activated more than once. This fixes that by ensuring that reply-type notifications are only destroyed when the activation type is
NSUserNotificationActivationTypeReplied
.Tested with https://gist.github.com/60a2cff9d13903bf538ebfc3c8134f0f.
cc @MarshallOfSound @zcbenz
Checklist
npm test
passesRelease Notes
Notes: Fixed an issue where notifications with a reply button could potentially be destroyed too early when a user clicked on the notification body before replying.