859168 - [Settings][Bluetooth] fire a bluetooth pairing notification when lock screen turn on

Status: VERIFIED FIXED

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

Description

[leo.bugzilla.gecko]

Dear Mozilla Team,

Bug848629 is same information.
But cannot see Bug815870 and duplicates.

Bug848629 and Bug815870, you will need to modify different parts.
Once I tried to edit the manually.

We will send you the patch file by email.
Please confirm.
Thanks.

Comment 1

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

Hi,

Could you give more description for the issue? I cannot understand what you have mentioned. Since Bug 815870 landed in Gaia master and v1-train, you could try to verify the issue via b2g18. Thank you.

Comment 2

[leo.bugzilla.gecko]

Attachment: pair request in lock screen

Dear Mozilla team,

I think that it can not receive pair message in lockscreen when another BT deviece sends a pair request.
Bug 815870 is about file-transfer but this is not.

I uploaded the patch code for pair request.
Please review this code which applied in gaia-master and v1-train.

Thanks.

Comment 3

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

It's more clear for the issue. It will show pairing message in lockscreen off. CC relative devs. Maybe they could know more defined behavior before.

Comment 4

[Dylan Oliver [:doliver]]

This issue was identified as a Leo QE1 blocker. Nominating for leo?

Comment 5

[Alex Keybl [:akeybl]]

leo.bugzilla.gecko - please create a pull request with your proposed patch.

We'll block on this because the screen timeout will likely be less than the pairing timeout.

Comment 6

[leo.bugzilla.gecko]

Attachment: Patch URL to pull request 9223

Comment 7

[leo.bugzilla.gecko]

Dear Mozilla Team,

I update the patch url.
Please review this.

Thanks.

Comment 8

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Change reviewer to Gaia team owner.

Comment 9

[Evelyn Hung]

Comment on attachment 738335 [details]
Patch URL to pull request 9223

This patch sends a notification when receiving pairing request but the screen is turned off or on the lockscreen. Loop UX to provide correct wording on the notification message.

Comment 10

[Evelyn Hung]

Hi stas, is it possible to add strings now?

Comment 11

[Evelyn Hung]

Comment on attachment 738335 [details]
Patch URL to pull request 9223

r- this patch mainly because we need UX confirm notification wording here, and my comments on the PR should be addressed.

Comment 12

[Evelyn Hung]

(In reply to Alex Keybl [:akeybl] from comment #5)
> leo.bugzilla.gecko - please create a pull request with your proposed patch.
> 
> We'll block on this because the screen timeout will likely be less than the
> pairing timeout.

I don't think this is a leo+ issue since it's not a general bluetooth pairing scenario. We ignore pairing request on purpose per the UX discussion a half year ago, because it will be annoyed if the user keeps receiving unexpected pairing requests when the phone is idle.

Comment 13

[leo.bugzilla.gecko]

Dear Evelyn,

(In reply to Evelyn Hung [:evelyn] from comment #12)
> (In reply to Alex Keybl [:akeybl] from comment #5)
> > leo.bugzilla.gecko - please create a pull request with your proposed patch.
> > 
> > We'll block on this because the screen timeout will likely be less than the
> > pairing timeout.
> 
> I don't think this is a leo+ issue since it's not a general bluetooth
> pairing scenario. We ignore pairing request on purpose per the UX discussion
> a half year ago, because it will be annoyed if the user keeps receiving
> unexpected pairing requests when the phone is idle.

If user keeps receiving unexpected pairing requests, it is maybe annoyed as your comment. But when screen is off, if bt device send the pair request to phone and user seems not recognize it. Then, it seems the device does not work.

Of course, this behavior is depending on the scenario. Because it is not a bug.
Please discuss with your UX team and decide it. And please tell me.

Thanks.

Comment 14

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

I think there is a proper scenario which can cover this bug. When user is trying to pair with Bluetooth 2.0 (legacy pairing) device, after user finished input pin code. Screen off due to screen timeout, the remote side cannot get PIN request dialog and it is required to let user pair again. That is also annoying.

User story might looks like:
(1) User turns on bluetooth car kit and use bluetooth car kit to search Unagi phone
(2) At the same time, user turns on screen and goto settings to make device discoverable
(3) Bluetooth discovering takes a lot time (probably over 30 seconds), when car kit searches the Unagi, unagi already screen off and enter into lock screen. User tries to pair with Unagi
(4) If user forgets to press power button to unlock lock screen, user would just feel pairing process failed.
I think it's a pretty common use case for bluetooth usage.

Comment 15

[Josh Carpenter [:jcarpenter]]

For version 1 we are fine not showing a prompt when the device is asleep. We accept that this may be suboptimal in some situations (like comment #14), but fixing the situation is easily resolved by the end user, and by not waking the lock screen we are at par with prior art. We are also past string freeze for 1.0.1 and 1.1.

A notification is also a suboptimal solution because it persist on the lock screen even after Bluetooth pairing request has expired. We feel we can do better, with the benefit of additional time.

Let's address this in future versions.

Comment 16

[Evelyn Hung]

Thanks for the feedback, Josh.
Renominate a "not leo+" issue.

Comment 17

[leo.bugzilla.gecko]

Dear Mozilla Team,

Thanks for your feedback.
I'll close this issue for reason of scenario, and this scenario is to get better in the future version.

Thanks.

Comment 18

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Track this in for future version.

Comment 19

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Since patch is ready but requires UX decision. Transfer this bug to Josh to follow up.

Comment 20

[Dylan Oliver [:doliver]]

Removing from QE1 milestone based on comment #17.

Comment 21

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Will this be followed up in the koi? How about resolving in m-c branch?

Comment 22

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

Need UX feedback.

Comment 23

[Stephany Wilkes]

I am flagging Carrie and Ayman, who worked on UX for Bluetooth, and Francis for any required lock screen clarification.

Comment 25

[Joe Cheng [:jcheng] (please needinfo)]

move to 1.3? depending on UX

Comment 26

[Joe Cheng [:jcheng] (please needinfo)]

move to bluetooth so it can be tracked with devices team

Comment 27

[ayman maat :maat]

Passing to carrie as she did the BT pairing UX work. ni? me if you require any assistance.

Comment 28

[Stephany Wilkes]

Removing ni? for Francis since Carrie has this.

Comment 29

[Joe Cheng [:jcheng] (please needinfo)]

BT to Neo

Bruce, this should goto backlog. thanks

Comment 30

[Neo Hsieh [:neo]]

Attachment: Bluetooth_Lockscreen_131025.pdf

Please check the UX specification document. Any questions please let me know.
Thanks

Comment 31

[Bruce Huang [:bhuang] (inactive)]

Adding to devices backlog.

Comment 32

[Joe Cheng [:jcheng] (please needinfo)]

added to backlog. minus

Comment 33

[Stephany Wilkes]

Hi Joe - just checking in. Is this getting moved to 1.4?

Comment 34

[Bruce Huang [:bhuang] (inactive)]

Hi Stephany, yes, this is on our list for 1.4.  Will follow up with Neo if further help is needed on the spec.

Comment 35

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

Hi Neo,

I have some question on the notification message. Don't we have the icon in front of the string "Bluetooth pairing request"? I'm not sure the icon is necessary or not. In case of Bluetooth file transfer, we always have the icon before the message. And there are two kinds of icon for confirmation dialog, transferring report.

Another question is no description message in the notification. Just want to confirm it again in the spec. comment 30. BTW, the tile message should be "Bluetooth pairing request". There is a typo error. Thanks.

Comment 36

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

Attachment: pull request 14598

Hi Evelyn,

Since still some UX input are unclear, I request feedback patch first. Once the string/icon are defined, I will update them in the pull request again. Thanks.

Comment 37

[Evelyn Hung]

Comment on attachment 8346396 [details] [review]
pull request 14598

I have no idea why we need this notification because I think it's not as important as missing call. I feel like the notification is annoying if someone keeps sending out pairing requests... 
But I'm fine if UX says so. feedback+ for the implementation.

Comment 38

[Neo Hsieh [:neo]]

Hi Rob, I try to send SMS or make a phone call to 1.3 mobile phone. That is no center line notification to user now. 
Is it our new design or bug?

Comment 39

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

Neo,

Just confirm for comment 38. Looks like a bug in build version 1.3 accidentally?! In Gaia master, it will show the notification on lock screen normally. Please help to give some input in comment 35. Thanks.:)

Comment 40

[Stephany Wilkes]

Neo, please check this on both 1.2 and 1.3 so Comment #35 can be addressed. Thanks!

Comment 41

[Neo Hsieh [:neo]]

Attachment: [e-mail]

Comment 42

[Neo Hsieh [:neo]]

OK

Comment 43

[Neo Hsieh [:neo]]

Attachment: Bluetooth_Lockscreen_131219.pdf

updated UX document

Comment 44

[Neo Hsieh [:neo]]

Attachment: Bluetooth_Lockscreen_131219_fixed.pdf

Typo fixed

Comment 45

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

Thanks for Neo's spec. updated. That's clear for me.:)

Comment 46

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

Comment on attachment 8346396 [details] [review]
pull request 14598

Hi Evelyn,

According to latest spec., I have updated the patch with description. The description is the name of pairing device. Please help to review it again. Thanks.

BTW, I found that Settings app is not able to receiving system message "bluetooth-pairing-request" while Settings app is not launched. Just add a console log at https://github.com/mozilla-b2g/gaia/blob/master/apps/settings/js/connectivity.js#L456 . I guess there is a bug in Gecko side.

Eric, Ben,

Could you please help to investigate the problem? Thanks a lot.

Comment 47

[Eric Chou [:ericchou] [:echou]]

(In reply to Ian Liu [:ianliu] from comment #46)
> Comment on attachment 8346396 [details] [review]
> pull request 14598
> 
> Hi Evelyn,
> 
> According to latest spec., I have updated the patch with description. The
> description is the name of pairing device. Please help to review it again.
> Thanks.
> 
> BTW, I found that Settings app is not able to receiving system message
> "bluetooth-pairing-request" while Settings app is not launched. Just add a
> console log at
> https://github.com/mozilla-b2g/gaia/blob/master/apps/settings/js/
> connectivity.js#L456 . I guess there is a bug in Gecko side.
> 
> Eric, Ben,
> 
> Could you please help to investigate the problem? Thanks a lot.

I don't have a device at hand right now, but I did find out that sometimes you have to touch the screen to trigger the pairing dialog. Seems like bug 915611?

Comment 48

[Eric Chou [:ericchou] [:echou]]

> BTW, I found that Settings app is not able to receiving system message
> "bluetooth-pairing-request" while Settings app is not launched. Just add a
> console log at
> https://github.com/mozilla-b2g/gaia/blob/master/apps/settings/js/
> connectivity.js#L456 . I guess there is a bug in Gecko side.
> 
> Eric, Ben,
> 
> Could you please help to investigate the problem? Thanks a lot.

Cannot reproduce with today's build on Nexus 4.

Comment 49

[Evelyn Hung]

Comment on attachment 8346396 [details] [review]
pull request 14598

r- sorry, but probably not your problem. 
After reading spec, I think there are some unclear behaviors and I'd like to confirm with UX. The major problem is in "request on idle mode" case: what if pairing session timeout? what does it happen if the user click on the notification after session timeout? To me, it doesn't make sense to display pairing window again.

Comment 50

[Eric Chou [:ericchou] [:echou]]

(In reply to Eric Chou [:ericchou] [:echou] from comment #48)
> > BTW, I found that Settings app is not able to receiving system message
> > "bluetooth-pairing-request" while Settings app is not launched. Just add a
> > console log at
> > https://github.com/mozilla-b2g/gaia/blob/master/apps/settings/js/
> > connectivity.js#L456 . I guess there is a bug in Gecko side.
> > 
> > Eric, Ben,
> > 
> > Could you please help to investigate the problem? Thanks a lot.
> 
> Cannot reproduce with today's build on Nexus 4.

I can reproduce by using today's build with Unagi. Will track in bug 915611.

Comment 51

[Neo Hsieh [:neo]]

Attachment: Bluetooth_Lockscreen_131223.pdf

Per discussed, Please check the new design. Thanks

Comment 52

[Evelyn Hung]

(In reply to Neo Hsieh from comment #51)
> Created attachment 8351127 [details]
> Bluetooth_Lockscreen_131223.pdf
> 
> Per discussed, Please check the new design. Thanks

It looks good to me. 
@Ian, can you give some feedback?

Comment 54

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

The latest spec. is also okay for me. As previous offline discussion with Arthur, we propose to listen two system message("bluetooth-pairing-request", "bluetooth-cancel") in system app. And handling confirm(should be alert) window in system app. Our reason are arming to reach the latest spec. as following.

1). In P6, once a user unlock the screen, we should show the attention screen immediately without click the notification. In settings app, we need to hold the pairing request. And listen the state change for key "lockscreen.locked". Before received "bluetooth-cancel" event, we will show the pairing screen while lock screen is unlocked. In system app, we just notify the message while receiving "bluetooth-pairing-request" in screen locked mode.

2). In P7, if there is a notification of pairing request, we will notify a message in pairing time out case. In settings app, just clear the flag for the holding pairing request. In system app, we have to notify a message and put the dialog in the "click" callback function.

Alive, we will need your feedback for the proposal since some additional modification in system app. Thanks.

Comment 55

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Ian Liu [:ianliu] from comment #54)
> The latest spec. is also okay for me. As previous offline discussion with
> Arthur, we propose to listen two system message("bluetooth-pairing-request",
> "bluetooth-cancel") in system app. And handling confirm(should be alert)
> window in system app. Our reason are arming to reach the latest spec. as
> following.
> 
> 1). In P6, once a user unlock the screen, we should show the attention
> screen immediately without click the notification. In settings app, we need
> to hold the pairing request. And listen the state change for key
> "lockscreen.locked". 

I haven't read all the story but I dislike this.

Comment 56

[Eric Chou [:ericchou] [:echou]]

Comment on attachment 8346396 [details] [review]
pull request 14598

Clear my fb? for now and I'll be happy to feedback again once final UX spec and implementation have been done.

Comment 57

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #55)
> > 1). In P6, once a user unlock the screen, we should show the attention
> > screen immediately without click the notification. In settings app, we need
> > to hold the pairing request. And listen the state change for key
> > "lockscreen.locked". 
> 
> I haven't read all the story but I dislike this.

I think we need to be careful about this. I dislike using settings key to do communication.
I propose to use the same mechanism for other attention screen: show pairing request on lockscreen instead of showing it after locked.

Comment 58

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

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #57)
> (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #55)
> > > 1). In P6, once a user unlock the screen, we should show the attention
> > > screen immediately without click the notification. In settings app, we need
> > > to hold the pairing request. And listen the state change for key
> > > "lockscreen.locked". 
> > 
> > I haven't read all the story but I dislike this.
> 
> I think we need to be careful about this. I dislike using settings key to do
> communication.
Yes, this is not a good way in checking settings key every time. But my proposal is arming to modify less code for bug fixing. In fact, we should not use attention screen to implement pairing request before. It has an ability to skip over lock screen module.

> I propose to use the same mechanism for other attention screen: show pairing
> request on lockscreen instead of showing it after locked.

Do you mean that the attention screen should be following up screen lock mechanism? It means that the attention screen is integrated in lock screen if the screen is locked. Not sure I misunderstand your proposal or not.

For original property of attention screen, it has higher priority than other dialog. It has the special ability to skip lock screen to do some thing. Such as incoming call, alarm goes off. So, I think we should not use attention screen in pairing request. It will make some security issue. A user is able to do pairing progress without unlock the screen. Unless attention screen is following up lock screen, it is fit to use the module for pairing progress.

Comment 60

[Neo Hsieh [:neo]]

Attachment: Bluetooth_Lockscreen_140205.pdf

Discussed with SW team (Gaia & Gecko), I changed the wording about active or passive for system structure.  If any question , Please let me know. Thanks

Comment 63

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

Just summary some advantages/disadvantages for refactor Bluetooth Pairing code base.

(A) Migrate it to Bluetooth App

# Advantages
** Bluetooth App manage the pairing process. Let Bluetooth modules be more focused.
** No new module is maintained in system app.

# Disadvantages
** Attention screen default behavior is not fit for a sample dialog. Becasue the pairing process is sample as a general dialog behavior(simpin, fxa, dialog).
** Have to hacking lockscreen settings in screen lock mode.
** Will need to fix dialog height problem in full screen app.
Mini status bar(minor).
** Once pairing request is coming, Bluetooth app should be launched.(Sometimes home screen app is killed, then we can see the background ref lashed.(minor))
** If we use a dialog show/hide to replace attention screen, we will need some work in Bluetooth launch page.
** Might meet chrome process issue(Pairing and sending file request in the same time.)
** All of above item are base on using current system message API.
** If “bluetooth-pairing-request” system message is replaced via event handler, this refactor work is a transition until v1.5.

(B) Migrate it to System App

# Advantages
** We could use system dialog to handle the sample dialog behavior.
** No need to handle dialog resizing while the keyboard is showing.(System dialog is supported in different window height mode.)
“bluetooth-pairing-request” system message will be replaced via event handler. The API document is updated on Wiki. It will be changed in v1.5 after discussion.(Gecko: There is performace issue and non-standerd concern in system message.)
** Notification is maintained more easily in the same app.

# Disadvantages
** System app have to maintain the pairing process.


I would like to use approach (B) for the refactor work. I think it's a better way in the feature. In fact, the pairing process is just a sample dialog. This is a good point to leave from attention screen. If someone have some suggestion, please feel free to join the discussion.:)

Comment 64

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

Attachment: a WIP for migrate pairing process to Bluetooth app

If we apply the patch, we could see some issue which is mentioned in comment 63, plan (A), # Disadvantages.

Comment 65

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Ian Liu [:ianliu] from comment #63)
> Just summary some advantages/disadvantages for refactor Bluetooth Pairing
> code base.
> 
> (A) Migrate it to Bluetooth App
> 
> # Advantages
> ** Bluetooth App manage the pairing process. Let Bluetooth modules be more
> focused.
> ** No new module is maintained in system app.
> 
> # Disadvantages
> ** Attention screen default behavior is not fit for a sample dialog. Becasue
> the pairing process is sample as a general dialog behavior(simpin, fxa,
> dialog).

What's sample dialog??
BTW please confirm the behavior of locked state with UX.

> ** Have to hacking lockscreen settings in screen lock mode.
> ** Will need to fix dialog height problem in full screen app.

Why ? If bluetooth app is launched via system message, current fullscreen app will be sent to background.

> Mini status bar(minor).
> ** Once pairing request is coming, Bluetooth app should be
> launched.(Sometimes home screen app is killed, then we can see the
> background ref lashed.(minor))

Don't think this is a problem.

> ** If we use a dialog show/hide to replace attention screen, we will need
> some work in Bluetooth launch page.
> ** Might meet chrome process issue(Pairing and sending file request in the
> same time.)
> ** All of above item are base on using current system message API.
> ** If “bluetooth-pairing-request” system message is replaced via event
> handler, this refactor work is a transition until v1.5.
> 
> (B) Migrate it to System App
> 
> # Advantages
> ** We could use system dialog to handle the sample dialog behavior.
> ** No need to handle dialog resizing while the keyboard is showing.(System
> dialog is supported in different window height mode.)
> “bluetooth-pairing-request” system message will be replaced via event
> handler. The API document is updated on Wiki. It will be changed in v1.5
> after discussion.(Gecko: There is performace issue and non-standerd concern
> in system message.)
> ** Notification is maintained more easily in the same app.
> 
> # Disadvantages
> ** System app have to maintain the pairing process.
> 
> 
> I would like to use approach (B) for the refactor work. I think it's a
> better way in the feature. In fact, the pairing process is just a sample
> dialog. This is a good point to leave from attention screen. If someone have
> some suggestion, please feel free to join the discussion.:)

Comment 66

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

(In reply to Alive Kuo [:alive][NEEDINFO!][:艾莉芙] from comment #65)
> (In reply to Ian Liu [:ianliu] from comment #63)
> > # Disadvantages
> > ** Attention screen default behavior is not fit for a sample dialog. Becasue
> > the pairing process is sample as a general dialog behavior(simpin, fxa,
> > dialog).
> 
> What's sample dialog??
wording error ^ simple
> BTW please confirm the behavior of locked state with UX.
According to latest spec. of comment 60, will give a notification centre and toast in locked state.
> 
> > ** Have to hacking lockscreen settings in screen lock mode.
> > ** Will need to fix dialog height problem in full screen app.
> 
> Why ? If bluetooth app is launched via system message, current fullscreen
> app will be sent to background.
I see there is an opacity status bar in the top of the dialog. Might be the window height is incorrect.
> 
> > Mini status bar(minor).
> > ** Once pairing request is coming, Bluetooth app should be
> > launched.(Sometimes home screen app is killed, then we can see the
> > background ref lashed.(minor))
> 
> Don't think this is a problem.
Yes, it's pretty minor.

Per offline discussion with Evelyn, and based on API refactor in v1.5, she agreed with (plan (B)). But, in the long tern, in order to lightweight system app, it's better to migrate it to Bluetooth App(plan (A)), if background service API is ready to work again(She said background service API go back to refactor.). That we don't need to depend on a running app for the pairing service.

Alive, do you agree the change?

Comment 67

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Ian Liu [:ianliu] from comment #66)
> I see there is an opacity status bar in the top of the dialog. Might be the
> window height is incorrect.

Please file a bug.
> 
> Per offline discussion with Evelyn, and based on API refactor in v1.5, she
> agreed with (plan (B)). But, in the long tern, in order to lightweight
> system app, it's better to migrate it to Bluetooth App(plan (A)), if
> background service API is ready to work again(She said background service
> API go back to refactor.). That we don't need to depend on a running app for
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> the pairing service.
^^^^^^^^^^^^^^^^^^^^^^

I really don't think so because you need UI to do pairing, please elaborate more.

> 
> Alive, do you agree the change?

What if we don't do anything but only observe lockscreen.locked to fire the notification?
Move in and out doesn't really make sense.

Comment 68

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

(In reply to Alive Kuo [:alive][NEEDINFO!][:艾莉芙] from comment #67)
> (In reply to Ian Liu [:ianliu] from comment #66)
> > I see there is an opacity status bar in the top of the dialog. Might be the
> > window height is incorrect.
> 
> Please file a bug.
Looks like the symptom is coming from Bug 979992. I'm fixing the 1.4+ first.
> > 
> > Per offline discussion with Evelyn, and based on API refactor in v1.5, she
> > agreed with (plan (B)). But, in the long tern, in order to lightweight
> > system app, it's better to migrate it to Bluetooth App(plan (A)), if
> > background service API is ready to work again(She said background service
> > API go back to refactor.). That we don't need to depend on a running app for
>                             
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > the pairing service.
> ^^^^^^^^^^^^^^^^^^^^^^
> 
> I really don't think so because you need UI to do pairing, please elaborate
> more.
Once the "bluetooth-pairing-request" system message is changed to Dom event in v1.5, I think that is no way to launch Bluetooth app to receive this message. In the shout tern, system app is the best solution for me until background service API working again. We could use background service to receive the event. Then, launch Bluetooth app itself. How do you think?
> 
> > 
> > Alive, do you agree the change?
> 
> What if we don't do anything but only observe lockscreen.locked to fire the
> notification?
> Move in and out doesn't really make sense.
If it makes sure to change "bluetooth-pairing-request" system message to be Dom event, I don't think move it in Bluetooth app make sense for me. There is WebBluetooth API discussion in Thursday. Might have a conclusion later. If the refactor work is blocking the issue here for a long time, we should fire a follow up bug for the big refactor. Let observe lockscreen.locked to fire the notification.

Comment 69

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Ian Liu [:ianliu] from comment #68)
> (In reply to Alive Kuo [:alive][NEEDINFO!][:艾莉芙] from comment #67)
> > (In reply to Ian Liu [:ianliu] from comment #66)
> > > I see there is an opacity status bar in the top of the dialog. Might be the
> > > window height is incorrect.
> > 
> > Please file a bug.
> Looks like the symptom is coming from Bug 979992. I'm fixing the 1.4+ first.
> > > 
> > > Per offline discussion with Evelyn, and based on API refactor in v1.5, she
> > > agreed with (plan (B)). But, in the long tern, in order to lightweight
> > > system app, it's better to migrate it to Bluetooth App(plan (A)), if
> > > background service API is ready to work again(She said background service
> > > API go back to refactor.). That we don't need to depend on a running app for
> >                             
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > the pairing service.
> > ^^^^^^^^^^^^^^^^^^^^^^
> > 
> > I really don't think so because you need UI to do pairing, please elaborate
> > more.
> Once the "bluetooth-pairing-request" system message is changed to Dom event
> in v1.5, I think that is no way to launch Bluetooth app to receive this
> message. In the shout tern, system app is the best solution for me until
> background service API working again. We could use background service to
> receive the event. Then, launch Bluetooth app itself. How do you think?

If we are chased by this kind of API change it be come back to bite when there's another API change.
But if there's no other choice for the API change (to DOM request) let's open another gaia bug for the change.

> > 
> > > 
> > > Alive, do you agree the change?
> > 
> > What if we don't do anything but only observe lockscreen.locked to fire the
> > notification?
> > Move in and out doesn't really make sense.
> If it makes sure to change "bluetooth-pairing-request" system message to be
> Dom event, I don't think move it in Bluetooth app make sense for me. There
> is WebBluetooth API discussion in Thursday. Might have a conclusion later.
> If the refactor work is blocking the issue here for a long time, we should
> fire a follow up bug for the big refactor. Let observe lockscreen.locked to
> fire the notification.

Please do since there seems no obvious pros neither to move into system nor all in bt app...

Comment 70

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

Ian, this bug is on your weekly report but there aren't any update. Would you might update what you had done with this bug for last week?

Comment 71

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

Comment on attachment 8346396 [details] [review]
pull request 14598

I was working WIP in this pull request. We could use Web Notification API to implement the feature here. It's able to update title/body message via "tag" property. It means that we can update the pairing request on notification when the request is timeout. So that we won't see two notifications(1. request. 2. Timeout) on the utility tray. The behaviours is expected from UX team before. I need to have some discussion with UX team here.

The other question is that we're able to use "bluetooth-cancel" system message to identify a timeout pairing request in passive mode. I overseer the situation, the timeout pairing request is coming with a "bluetooth-cancel" system message.

Comment 72

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

(In reply to Ian Liu [:ianliu] from comment #71)
> Comment on attachment 8346396 [details] [review]
> pull request 14598
> 
> The other question is that we're able to use "bluetooth-cancel" system
> message to identify a timeout pairing request in passive mode. I overseer
                                                                   ^ observe 
> the situation, the timeout pairing request is coming with a
> "bluetooth-cancel" system message.

Hi Jamin,

Shall we use "bluetooth-cancel" system message to identify the later pairing request which is become timeout in passive mode? Thanks.

Comment 73

[Jamin Liu [:jaliu][:Jamin]]

Hi Ian,

Since we don't use DOMRequest for pairing in passive mode, it seems "bluetooth-cancel" system message is our only option to monitor the cases such like "Cancel" or "Timeout".
P.S. We could use req.error.name to determine the failure cases in initiative mode.

I think it's reasonable to use "bluetooth-cancel" to identify pairing timeout.
However, I notice gecko wouldn't send "bluetooth-cancel" in some cases of incoming pairing (passive mode).

Here is a brief for my pairing experiment. (Android send a pair request to FFOS.)

Passive mode: (i.e. receive a paring request)
case 1. The requester click "Cancel" button.
  -> Would send "bluetooth-cancel"
case 2. Both device ignore the dialog and get timeout.
  -> Would send "bluetooth-cancel"
case 3. Our device click "Cancel" button.
  -> Would't sent any system message. (It seems reasonable to me.)
case 4. Our device click "Pair" button, then the requester click "Cancel" button.
  -> Would't sent any system message.
case 5. Our device click "Pair" button, but the requester don't click "Confirm" button and get timeout.
  -> Would't sent any system message.

With current Gecko implementation, if the requester cancel the request when adapter.setPairingConfirmation() has been called, Gaia may not receive "bluetooth-cancel".

There seems to be a problem with handling the case 4 and case 5.
I'll discuss with Eric tomorrow.

Comment 74

[Jamin Liu [:jaliu][:Jamin]]

Ian, Eirc and I had a face to face discussion this morning.
We think it's OK to use "bluetooth-cancel" system message to identify the pairing request which is become timeout in passive mode.

If lock screen was turned on, we wouldn't hit case 4 or case 5.
The "bluetooth-cancel" system message should be work in the most cases

Generally, gecko would send "bluetooth-cancel" to Gaia when it hit case 1, case 2 and case 3.
Although, in some edge cases, the pairing requester wouldn't send the "timeout" notification to us due to its Bluetooth stack implementation. 
We don't have a plan to support this type of edge cases with Bluez stack, specifically we plan to drop it and use Bluedroid instead in future.

Comment 75

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

(In reply to Jamin Liu [:jaliu] from comment #74)
> Ian, Eirc and I had a face to face discussion this morning.
> We think it's OK to use "bluetooth-cancel" system message to identify the
> pairing request which is become timeout in passive mode.
> 
> If lock screen was turned on, we wouldn't hit case 4 or case 5.
> The "bluetooth-cancel" system message should be work in the most cases
> 
> Generally, gecko would send "bluetooth-cancel" to Gaia when it hit case 1,
> case 2 and case 3.
> Although, in some edge cases, the pairing requester wouldn't send the
> "timeout" notification to us due to its Bluetooth stack implementation. 
> We don't have a plan to support this type of edge cases with Bluez stack,
> specifically we plan to drop it and use Bluedroid instead in future.

Jamin, thanks for your summary. That's is pretty clear for our experiment. For the edge case, I think that the reproduce rate is lower. And it would not be blocker. The worse case is that a user confirm a passive pairing request which is overdue already. Then, the passive pairing request will be cancel in result, even if a user click "Pair". Since WebBluetooth v2 is ongoing, we could take care the edge case and paired "pairing-request" for each pairing flow.

Comment 76

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

Hi Omega, per our offline discussion in Web Notification ability. We are able to group(combine) the two notifications(https://bugzilla.mozilla.org/show_bug.cgi?id=859168#c60 spec. p5, flow 4, *a. Bluetooth pairing is requesting. *b. Bluetooth pairing was requested by %s %t). For the notification here, there is still some suspicion that we need to take a look. I summarise some discussion that we mentioned face to face.

1. Grouping notification as above comment.
2. The duplicated time stamp might make a use confused. We already provide time stamp for each notification. And the grouping notification will let a user see the latest pairing state.
3. The two notifications *a and *b are string truncated. We might give a simply description for the title. Please take a look in toast and utility tray.
4. To provide only one notification for indicating pairing request in screen locked mode. Since notification grouping ability is ready, we could show one in this use case. The later passive pairing requests are timeout and useless. I would like to suggest grouping them.
5. Some wording and new line in the confirm window(spec. p7, flow 4) are needed to revise.

Thanks for your discussion with patience:)

Comment 77

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

Comment on attachment 8346396 [details] [review]
pull request 14598

This patch is updated and revised according to latest spec. after offline discussion. Jamin, Arthur, could you please give some feedback for improving flow. Thanks.

Comment 78

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

Leave dependancy from bug 964653 since the pr here is not relative with system app.

Comment 79

[Omega Feng [:Omega] [:馮於懋]]

Attachment: Bluetooth_Lockscreen_140401.pdf

Here is the updated spec.

Comment 80

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

What's the status of this bug? Why is this is being worked on but not marked as ASSIGNED?

Comment 81

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

Thanks for your reminder. I forgot to mark it ASSIGNED.

Comment 82

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

... and what's the status of this bug?

Comment 83

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

According to comment 29, there is a little different with offline discussion before. The notification callback should be update without title string change. The title is always remaining "Bluetooth pairing request". I will update my WIP to meet the small change. It's almost there beside of the unit test..

Comment 84

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

Comment on attachment 8346396 [details] [review]
pull request 14598

Arthur, the patch is updated with UX spec. in comment 29. Could you please help to review my pr? Then, I will add unit test base on the final patch. Thanks.

Comment 85

[Arthur Chen [:arthurcc][inactive after 6/30]]

Comment on attachment 8346396 [details] [review]
pull request 14598

Overall it works well and looks good to me. Please check my github comment for some minor issues, thanks!

Comment 86

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

Comment on attachment 8346396 [details] [review]
pull request 14598

Arthur, thanks for your reviewing effort. I have revised my patch and leave some comment on GitHub. Please help me for the reviewing process again. Thanks.:)

Comment 87

[Arthur Chen [:arthurcc][inactive after 6/30]]

Comment on attachment 8346396 [details] [review]
pull request 14598

The patch looks good to me. Please add at least one unit test to ensure that when the dom event "bluetooth-pairing-request" fires, the notification is created (or not created) based on the state of the lock screen, thanks!

Comment 88

[Alison Shiue]

https://moztrap.mozilla.org/manage/cases/?&pagenumber=1&pagesize=100&sortfield=created_on&sortdirection=desc&filter-tag=2613&filter-suite=182

Comment 89

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

After bug 1003739 landed, I will refine the patch here again.

Comment 90

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

Attachment: pull request 19474

Hi Arthur, 

Base on comment 87, I create a new pull request for working in Bluetooth app since 90% of pairing process is located in Bluetooth app. Could you please help to review it again? Partial of the patch is same with https://github.com/mozilla-b2g/gaia/pull/14598. And I will add unit test soon. Thanks.

Comment 91

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

Comment on attachment 8346396 [details] [review]
pull request 14598

Per comment 90, obsolete the useless patch for settings app.

Comment 92

[Arthur Chen [:arthurcc][inactive after 6/30]]

Comment on attachment 8426124 [details] [review]
pull request 19474

Good work, Ian. Overall there are a few minor issues. Please check my comments in github. And please also add tests for the newly added functions. Thanks!

Comment 93

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

Comment on attachment 8426124 [details] [review]
pull request 19474

Arthur, thanks for reviewing work with patient. I have revised and added unit test for cover overall changes in this patch. Please help to review again.

Comment 94

[Arthur Chen [:arthurcc][inactive after 6/30]]

Comment on attachment 8426124 [details] [review]
pull request 19474

r=me, thanks for the effort!

Comment 95

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

Since the pr is landed, we can close the issue now.

Gaia/master: 391a06139a379a04fef7cabbd31896a05148c80a

Comment 96

[Alison Shiue]

Verified on 
Gaia      a38a6a5c6fabc97dd16d5360632b5ac5c7e06241
Gecko     https://hg.mozilla.org/mozilla-central/rev/951e3a671279
BuildID   20140604160202
Version   32.0a1