Windows MSIX Packaged App: onDidReceiveNotificationResponse not invoked, app protocol invoked instead

[aweinber]

Describe the bug

Windows notifications' callbacks aren't invoking for me when the flutter app is packaged with msix.

• When I run the app locally using flutter run, my notification shows and clicking buttons on the notification invokes the method passed to onDidReceiveNotificationResponse
• When I build the exact same app using msix, the method is not invoked, and instead my app protocol is invoked with the WindowsAction arguments.

To Reproduce

0. Init the notification handler with a callback method and package it through msix
1. Trigger a notification that contains a WindowsAction
2. Click on that action
3. Observe whether your callback method was invoked
   3.b. Observe whether the app was invoked with a protocol instead

Expected behavior

I would think that the method could be invoked directly, but maybe not.

Sample code to reproduce the problem

// set up
    final WindowsInitializationSettings initializationSettingsWindows =
        WindowsInitializationSettings(
            appName: 'MyApp',
            appUserModelId: 'myapp.integ',
            guid: 'bbd0ec6f-fac7-4236-a0a8-8363d226b5e6', // random guid
            iconPath: Env.iconPath); 
    final InitializationSettings initializationSettings = InitializationSettings(
      windows: initializationSettingsWindows,
    );
    await flutterLocalNotificationsPlugin!.initialize(
      initializationSettings,
      onDidReceiveNotificationResponse: onNotificationResponse,
    );
    _notificationsPlugin = flutterLocalNotificationsPlugin;

// invoke notification
      final NotificationDetails notificationDetails = NotificationDetails(
        windows: WindowsNotificationDetails(                  
          actions: [
            WindowsAction(
              content: 'Discard',
              arguments: 'action=discard&text=%1', // tried to template the text using {text_input} and %1
              buttonStyle: WindowsButtonStyle.critical,
            ),
          ...
         ],
        inputs: [
            WindowsTextInput( // reason that protocol workaround isn't working
              id: 'text_input',            
              placeHolderContent: 'write some text here,
              title: 'Edit Field',
            ),
          ],
    ),
  )
      await _notificationsPlugin.show(
        DateTime.now().millisecondsSinceEpoch,
        'New message',
        notificationTitle,
        notificationDetails,
      );

 
// callback method
  void onNotificationResponse(NotificationResponse response) {
    _logger.info('Notification response received: ${response.actionId}, ${response.payload}');
}

build with msix using myapp.integ as the identity

Thanks @Levi-Lesches for setting all this up - it is quite helpful, and I can try to work around the lack of callback, except that I don't believe there's any way to capture data input to the notification through the callback. I tried a few different templates with no success. It's also possible that I have misconfigured something, but figured since this is a new feature that it may just be an unsupported behavior that you haven't noticed yet.

[Levi-Lesches]

Thanks for the report! On first glance, this seems like it might be by design. A few questions to give me more context:

• is your msix closed when you click the notification? If so, did you try reading the app launch details?
• did you try setting WindowsActivationType on the action?
• how are you getting the arguments from the app protocol invocation? In other words, what's your workaround?

I'll be able to run your code later, not at my computer now

[aweinber]

Thanks for quick response. Short answers:

• My app is open while I'm running these
• I didn't set WindowsActivationType, so it would have used the foreground default. I just tried this, no difference
• My app uses WindowsSingleInstance to make sure that only a single instance of the app gets launched when we have oauth or other callbacks. Here's what that looks like:

  await WindowsSingleInstance.ensureSingleInstance(
    args, Env.executionAlias,
    onSecondWindow: handleProtocol,
    bringWindowToFront: false
  );

onSecondWindow accepts a list of args that are passed (i.e. myapp://code=xyz gets returned as ["code=xyz"], and from there I do whatever)

==

Wouldn't surprise me if it's by design - just would imagine there's a way to wire through all the data contained in the NotificationResponse through the protocol as well.

[Levi-Lesches]

Hm, am I missing something? Your MSIX app is opened, you show a notification with text input, and wish to get the input within your Flutter code. Here I'm able to do exactly that in the example (you can see the text indicating this is running as an MSIX).

20250117-0058-46.0032672.mp4

Maybe WindowsSingleInstance is blocking this somehow? Please confirm by running the example, seeing that it works, and try breaking it by adding WindowsSingleInstance.