fix(messaging,macos): unwrap UNNotificationResponse launch payload so getInitialMessage returns it - #18527
Conversation
On macOS, NSApplicationLaunchUserNotificationKey can hold a UNNotificationResponse. That class exposes only `notification` and `actionIdentifier` -- the payload lives at notification.request.content.userInfo -- so it does not respond to `userInfo` and fell through every existing branch, leaving remoteNotification nil. getInitialMessage() then resolved with null when the app was launched by tapping a notification. Adds an explicit UNNotificationResponse branch ahead of the respondsToSelector check, keeping the existing NSDictionary and NSUserNotification paths intact. Verified against the macOS 26.5 SDK that UNNotificationResponse does not respond to `userInfo` while UNNotificationContent does. The fix was originally reported and written by @steffenhaak in #17231. Reopening it here because fork PRs only receive 4 of the 46 CI checks, so the iOS and macOS jobs that exercise this code never ran there. Fixes #17230.
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. |
|
Thx 🙏 |
Description
Note
This fix was originally reported and written by @steffenhaak in #17231. All credit for
diagnosing it goes to them. It is reopened here only because fork PRs receive 4 of the
46 CI checks on this repo, so the iOS and macOS jobs that exercise this code never ran
on the original branch.
On macOS,
NSApplicationLaunchUserNotificationKeycan hold aUNNotificationResponse.That class declares only two properties:
The payload lives at
notification.request.content.userInfo, so aUNNotificationResponsedoes not respond to
userInfoand fell through every branch inapplication_onDidFinishLaunchingNotification:, leavingremoteNotificationasnil.getInitialMessage()then resolved withnullwhenever the app was launched by tapping anotification.
#18457 fixed the related hang (a
nilpayload no longer blocks forever), but not theextraction — so the payload was still being dropped.
This adds an explicit
UNNotificationResponsebranch ahead of therespondsToSelector:check, leaving the existing
NSDictionaryand deprecatedNSUserNotificationpathsuntouched. The original PR replaced those paths rather than extending them, which would
have regressed the cases #18457 deliberately handles.
Verified against the macOS 26.5 SDK at runtime:
userInfoUNNotificationResponseUNNotificationContentRelated Issues
application_onDidFinishLaunchingNotification#17231Checklist
///).melos run analyze) does not report any problems on my PR.Breaking Change