1880863 - BrowserContentHandler does not parse notification data when tag was handled

Status: NEW

(Toolkit :: Alerts Service, defect, P3)

Description

[Kagami Rosylight [:saschanaz] (they/them)]

(BrowserContentHandler is technically not in this component but I think this specific part belongs to here)

The JSON parsing happens when !tagWasHandled, which redefines the variable notificationData. But if tagWasHandled is not false, it remains to be a string, and then all the member accesses below that block returns undefined.

As a result, the code block that presumably intended to run with web notifications never runs if tag is handled.

I think maybe the code intended to return early when tag is handled as there's no point to go further?

Comment 1

[Nick Alexander :nalexander [he/him]]

I think maybe the code intended to return early when tag is handled as there's no point to go further?

You are correct -- if the tag is handled by a Windows 8.1-style callback (i.e., the notification was from this instance), then we shouldn't continue to process the notificationData.

P3 since we should fix this, S4 since it's harmless (AFAIK). We have 2 projects that might pick this up: WDBA changes and more background update notifications. Thanks for flagging!

When we address this, here's what I'm thinking of. First, we want to extract the action string from the notification itself rather than passing it on the command line as well. (This might impact relaunching into Firefox from a background task; that remains to be addressed.). Second, I'd like to see the handling of the relaunch actions handled within the alert service itself, so that there's less detail spilling out into BrowserContentHandler. (That might be tricky because we want to use the launch process URL handling, but surely there's a way to accommodate both.)