Closed Bug 1114907 Opened 10 years ago Closed 10 years ago

[Bluetooth File Transfer] Notification will not be closed after a user clicked them.


(Firefox OS Graveyard :: Gaia::Bluetooth, defect)

Gonk (Firefox OS)
Not set


(blocking-b2g:2.2+, b2g-v2.1 unaffected, b2g-v2.2 fixed)

2.2 S3 (9jan)
blocking-b2g 2.2+
Tracking Status
b2g-v2.1 --- unaffected
b2g-v2.2 --- fixed


(Reporter: iliu, Assigned: zbraniecki)



(Keywords: regression)


(1 file)

As title. 

Expected Result: The notification should be closed after a user clicked on them.
Hi Zibi,

Since bug 1095109 landed, the NotificationHelper module won't close notification automatically after a user clicked on it.

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
Flags: needinfo?(gandalf)
Triage: + for regression.
Blocks: 1095109
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.
Flags: needinfo?(kgrandon)
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?
Flags: needinfo?(kgrandon)
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.
Flags: needinfo?(kgrandon)
Attached file pull request
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+
In master:
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.2 S3 (9jan)
You need to log in before you can comment on or make changes to this bug.