As title. Expected Result: The notification should be closed after a user clicked on them.

The issue might be happened after bug 1095109 landed. https://github.com/mozilla-b2g/gaia/commit/0833002fdf6a33d44590d6b8c728a03f7eccd977

Hi Zibi, Since bug 1095109 landed, the NotificationHelper module won't close notification automatically after a user clicked on it. https://github.com/mozilla-b2g/gaia/commit/0833002fdf6a33d44590d6b8c728a03f7eccd977#diff-f6e6a044ffbb9c58c6138b3b5b63e7c2L46 I see `NotificationHelper.send` will return the created notification in the resolve function. I think you would like to expose the notification life cycle to the caller. So that will have to give a fixing patch here.

Triage: + for regression.

Sure. Kevin, what do you want me to do here? I'd like to stick to W3C API as close as possible, so if W3C Notification doesn't close automatically, I'd prefer to revisit the changes and close it in the event handler in client-code over implicitly by the NotificationHelper. Does it sound good? Ian, I'll be happy to takeover the bug and fix it, if you are ok with it.

NotificationHelper implies helper so I think it's fine to extend the API to add additional functionality here. My preference would be to add the code to the helper to restore the previous behavior.

Zibi, As Kevin mentioned in comment 5, I'm okay to pass the issue to you since an ongoing fixing in NotificationHelper. If your decision is fixing in client side, I'm happy to takeover the issue again. Because the client has more control over the helper for its specific user story.

BTW, I find out functionality of Bluetooth file transfer is not stable recently(master). Especially, in case of send/receive files after transferred completely. I suspect the unclose notification might make the functionality blocking. Please manually checking them after fixing patch is ready. Thanks.

Kevin: my only problem with your proposal is that it seems like it will force all use cases of NotificationHelper to follow the close-on-click approach. Since I want to migrate all Notification API uses to use NotificationHelper, if there's any scenario in which we might not want it, I'd have to add a flag to prevent this behavior. Do you prefer this over implementing close-on-click on client-side code?

Can you tell me some cases today where we wouldn't want to hide on tap? The UX consistency of always performing the same action here is probably ideal, so my preference is to hide the notification in the helper.

Android and iOS definitely have notifications that are linking to settings page but are not dismissed until some further action is undertaken (Bluetooth enabled/disabled, USB debugging disabled, alarm dismissed etc.) So I added a Boolean flag to disable auto close-on-click. Let me know if that will work for you :)

Comment on attachment 8541328 [details] pull request We should add a unit test for this, but since it doesn't have an existing unit test file, let's land for now and we can work on the test later. Thanks!

In master: https://github.com/mozilla-b2g/gaia/commit/3554ea9504046646b4679e3a61317c49fc55ca87