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

Status: RESOLVED FIXED

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

Description

[[e-mail], [e-mail]]

As title. 

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

Comment 1

[[e-mail], [e-mail]]

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

Comment 2

[[e-mail], [e-mail]]

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.

Comment 3

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Triage: + for regression.

Comment 4

[Zibi Braniecki [:zbraniecki][:gandalf]]

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.

Comment 5

[Kevin Grandon :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.

Comment 6

[[e-mail], [e-mail]]

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.

Comment 7

[[e-mail], [e-mail]]

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.

Comment 8

[Zibi Braniecki [:zbraniecki][:gandalf]]

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?

Comment 9

[Kevin Grandon :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.

Comment 10

[Zibi Braniecki [:zbraniecki][:gandalf]]

Attachment: 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 :)

Comment 11

[Kevin Grandon :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!

Comment 12

[Kevin Grandon :kgrandon]

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