Closed Bug 1114907 Opened 6 years ago Closed 6 years ago
[Bluetooth File Transfer] Notification will not be closed after a user clicked them
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.
Assignee: nobody → iliu
Triage: + for regression.
blocking-b2g: 2.2? → 2.2+
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.
Flags: needinfo?(gandalf) → needinfo?(kgrandon)
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.
Assignee: iliu → gandalf
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 :)
Attachment #8541328 - Flags: review?(kgrandon)
Comment on attachment 8541328 [details] [review] 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!
Attachment #8541328 - Flags: review?(kgrandon) → review+
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.