Skip to content

fix(messaging,macos): unwrap UNNotificationResponse launch payload so getInitialMessage returns it - #18527

Merged
Lyokone merged 1 commit into
mainfrom
fix/macos-notification-launch-payload
Aug 4, 2026
Merged

fix(messaging,macos): unwrap UNNotificationResponse launch payload so getInitialMessage returns it#18527
Lyokone merged 1 commit into
mainfrom
fix/macos-notification-launch-payload

Conversation

@Lyokone

@Lyokone Lyokone commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

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, NSApplicationLaunchUserNotificationKey can hold a UNNotificationResponse.
That class declares only two properties:

@interface UNNotificationResponse : NSObject <NSCopying, NSSecureCoding>
@property (readonly, copy) UNNotification *notification;
@property (readonly, copy) NSString *actionIdentifier;

The payload lives at notification.request.content.userInfo, so a UNNotificationResponse
does not respond to userInfo and fell through every branch in
application_onDidFinishLaunchingNotification:, leaving remoteNotification as nil.
getInitialMessage() then resolved with null whenever the app was launched by tapping a
notification.

#18457 fixed the related hang (a nil payload no longer blocks forever), but not the
extraction — so the payload was still being dropped.

This adds an explicit UNNotificationResponse branch ahead of the respondsToSelector:
check, leaving the existing NSDictionary and deprecated NSUserNotification paths
untouched. 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:

Class responds to userInfo
UNNotificationResponse NO — hence the dropped payload
UNNotificationContent YES — the keypath used here

Related Issues

Checklist

  • I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
  • All existing and new tests are passing.
  • I updated/added relevant documentation (doc comments with ///).
  • The analyzer (melos run analyze) does not report any problems on my PR.
  • I read and followed the Flutter Style Guide.
  • I signed the CLA.
  • I am willing to follow-up on review comments in a timely manner.

Breaking Change

  • Yes, this is a breaking change.
  • No, this is not a breaking change.

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.
@gemini-code-assist

Copy link
Copy Markdown
Contributor
Using Gemini Code Assist

The 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 /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

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 .gemini/ folder in the base of the repository. Detailed instructions can be found here.

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.

@Lyokone
Lyokone merged commit 584acc9 into main Aug 4, 2026
42 of 46 checks passed
@Lyokone
Lyokone deleted the fix/macos-notification-launch-payload branch August 4, 2026 13:40
@steffenhaak

Copy link
Copy Markdown

Thx 🙏

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[firebase_messaging]: Notification click if app is terminated leads to blank screen on launched app

4 participants