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

VERIFIED FIXED in 2.0 S3 (6june)

Status

Firefox OS
Bluetooth
P2
major
VERIFIED FIXED
5 years ago
4 years ago

People

(Reporter: leo.bugzilla.gecko, Assigned: iliu@mozilla.com, ianliu.moz@gmail.com)

Tracking

unspecified
2.0 S3 (6june)
ARM
Gonk (Firefox OS)
Dependency tree / graph
Bug Flags:
in-moztrap +

Firefox Tracking Flags

(blocking-b2g:-, feature-b2g:2.0)

Details

(Whiteboard: [TD-9530], interaction, [devices-triaged], [ucid:BTP20, 2.0, ft:devices], [p=3])

Attachments

(6 attachments, 6 obsolete attachments)

(Reporter)

Description

5 years ago
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.
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.
(Reporter)

Comment 2

5 years ago
Created attachment 734512 [details]
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.
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.
Component: Gaia::Bluetooth File Transfer → Gaia::Settings
Hardware: x86_64 → ARM
Summary: [Bluetooth]Lock screen when it does not have a pairing request → [Settings][Bluetooth] No pairing device message when lock screen turn on
(Reporter)

Updated

5 years ago
Whiteboard: [TD-9530]
This issue was identified as a Leo QE1 blocker. Nominating for leo?
blocking-b2g: --- → leo?
Target Milestone: --- → Leo QE1 (5may)

Comment 5

5 years ago
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.
Assignee: nobody → leo.bugzilla.gecko
blocking-b2g: leo? → leo+
(Reporter)

Comment 6

5 years ago
Created attachment 738335 [details]
Patch URL to pull request 9223
Attachment #738335 - Flags: review?(shuang)
(Reporter)

Comment 7

5 years ago
Dear Mozilla Team,

I update the patch url.
Please review this.

Thanks.
Attachment #738335 - Flags: review?(shuang) → review?(ehung)
Change reviewer to Gaia team owner.

Comment 9

5 years ago
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.
Attachment #738335 - Flags: feedback?(lco)
Attachment #738335 - Flags: feedback?(jcarpenter)

Comment 10

5 years ago
Hi stas, is it possible to add strings now?
Flags: needinfo?(stas)

Comment 11

5 years ago
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.
Attachment #738335 - Flags: review?(ehung) → review-

Comment 12

5 years ago
(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.
(Reporter)

Comment 13

5 years ago
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.
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.
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.
Whiteboard: [TD-9530] → [TD-9530], interaction

Comment 16

5 years ago
Thanks for the feedback, Josh.
Renominate a "not leo+" issue.
blocking-b2g: leo+ → leo?
Flags: needinfo?(stas)

Updated

5 years ago
Attachment #738335 - Flags: feedback?(lco)
Attachment #738335 - Flags: feedback?(jcarpenter)
(Reporter)

Comment 17

5 years ago
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.
Priority: -- → P2

Updated

5 years ago
blocking-b2g: leo? → -
(Reporter)

Updated

5 years ago
Assignee: leo.bugzilla.gecko → shuang
Track this in for future version.
blocking-b2g: - → koi?
Assignee: shuang → jcarpenter
Since patch is ready but requires UX decision. Transfer this bug to Josh to follow up.
Removing from QE1 milestone based on comment #17.
Target Milestone: 1.1 QE1 (5may) → ---
Will this be followed up in the koi? How about resolving in m-c branch?

Updated

5 years ago
blocking-b2g: koi? → koi+
Need UX feedback.
Assignee: jcarpenter → nobody
Flags: needinfo?(firefoxos-ux-bugzilla)

Comment 23

5 years ago
I am flagging Carrie and Ayman, who worked on UX for Bluetooth, and Francis for any required lock screen clarification.
Flags: needinfo?(firefoxos-ux-bugzilla)
Flags: needinfo?(fdjabri)
Flags: needinfo?(cawang)
Flags: needinfo?(aymanmaat)
Duplicate of this bug: 912870
move to 1.3? depending on UX
blocking-b2g: koi+ → 1.3?
Whiteboard: [TD-9530], interaction → [TD-9530], interaction, [devices-triaged]
move to bluetooth so it can be tracked with devices team
Component: Gaia::Settings → Bluetooth

Comment 27

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

Updated

5 years ago
Flags: needinfo?(aymanmaat)

Comment 28

5 years ago
Removing ni? for Francis since Carrie has this.
Flags: needinfo?(fdjabri)
BT to Neo

Bruce, this should goto backlog. thanks
Flags: needinfo?(nhsieh)
Flags: needinfo?(cawang)
Flags: needinfo?(bhuang)

Comment 30

5 years ago
Created attachment 822181 [details]
Bluetooth_Lockscreen_131025.pdf

Please check the UX specification document. Any questions please let me know.
Thanks
Flags: needinfo?(nhsieh) → needinfo?(jcheng)
Flags: needinfo?(jcheng)
Adding to devices backlog.
Blocks: 905001
Flags: needinfo?(bhuang)
added to backlog. minus
blocking-b2g: 1.3? → -

Comment 33

4 years ago
Hi Joe - just checking in. Is this getting moved to 1.4?
Flags: needinfo?(jcheng)
Hi Stephany, yes, this is on our list for 1.4.  Will follow up with Neo if further help is needed on the spec.
Flags: needinfo?(jcheng)
(Assignee)

Updated

4 years ago
Assignee: nobody → iliu
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.
Flags: needinfo?(nhsieh)
Created attachment 8346396 [details] [review]
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.
Attachment #8346396 - Flags: feedback?(ehung)

Updated

4 years ago
Summary: [Settings][Bluetooth] No pairing device message when lock screen turn on → [Settings][Bluetooth] fire a bluetooth pairing notification when lock screen turn on

Comment 37

4 years ago
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.
Attachment #8346396 - Flags: feedback?(ehung) → feedback+

Comment 38

4 years ago
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?
Flags: needinfo?(nhsieh) → needinfo?(rmacdonald)
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.:)
Flags: needinfo?(rmacdonald) → needinfo?(nhsieh)

Comment 40

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

Comment 41

4 years ago
Created attachment 8349936 [details]
actionicon_notification_bluetooth@1.png
Flags: needinfo?(nhsieh) → needinfo?(iliu)

Comment 42

4 years ago
OK

Comment 43

4 years ago
Created attachment 8349965 [details]
Bluetooth_Lockscreen_131219.pdf

updated UX document

Comment 44

4 years ago
Created attachment 8349968 [details]
Bluetooth_Lockscreen_131219_fixed.pdf

Typo fixed
Thanks for Neo's spec. updated. That's clear for me.:)
Flags: needinfo?(iliu)
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.
Attachment #8346396 - Flags: review?(ehung)
Attachment #8346396 - Flags: feedback?(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?
See Also: → bug 915611
> 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

4 years ago
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.
Attachment #8346396 - Flags: review?(ehung) → review-
Flags: needinfo?(nhsieh)
(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

4 years ago
Created attachment 8351127 [details]
Bluetooth_Lockscreen_131223.pdf

Per discussed, Please check the new design. Thanks
Attachment #822181 - Attachment is obsolete: true
Attachment #8349965 - Attachment is obsolete: true
Attachment #8349968 - Attachment is obsolete: true
Flags: needinfo?(nhsieh) → needinfo?(ehung)

Comment 52

4 years ago
(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?
Flags: needinfo?(ehung)
(Assignee)

Updated

4 years ago
Duplicate of this bug: 897413
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.
Flags: needinfo?(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 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.
Attachment #8346396 - Flags: feedback?(echou)
(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.
Flags: needinfo?(alive)
(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.

Updated

4 years ago
Duplicate of this bug: 960920
(Assignee)

Updated

4 years ago
Depends on: 964653

Comment 60

4 years ago
Created attachment 8370590 [details]
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
(Assignee)

Updated

4 years ago
Duplicate of this bug: 896407

Updated

4 years ago
Duplicate of this bug: 977986
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.:)
Created attachment 8384509 [details] [review]
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.
(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.:)
(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?
(Assignee)

Updated

4 years ago
Flags: needinfo?(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.
Flags: needinfo?(alive)
(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.
Flags: needinfo?(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...
Flags: needinfo?(alive)
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?
Flags: needinfo?(iliu)
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.
Attachment #8346396 - Flags: review-
Flags: needinfo?(iliu)
(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.
Flags: needinfo?(jaliu)
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.
Flags: needinfo?(jaliu)
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.
(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.
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:)
Flags: needinfo?(ofeng)
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.
Attachment #8346396 - Flags: feedback?(jaliu)
Attachment #8346396 - Flags: feedback?(arthur.chen)
Leave dependancy from bug 964653 since the pr here is not relative with system app.
No longer depends on: 964653
Attachment #8346396 - Flags: feedback?(jaliu) → feedback+
Created attachment 8399836 [details]
Bluetooth_Lockscreen_140401.pdf

Here is the updated spec.
Attachment #8351127 - Attachment is obsolete: true
Attachment #8370590 - Attachment is obsolete: true
Flags: needinfo?(ofeng)
What's the status of this bug? Why is this is being worked on but not marked as ASSIGNED?
Status: NEW → ASSIGNED
Flags: needinfo?(iliu)
Thanks for your reminder. I forgot to mark it ASSIGNED.
Flags: needinfo?(iliu)
... and what's the status of this bug?
Flags: needinfo?(iliu)
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..
Flags: needinfo?(iliu)
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.
Attachment #8346396 - Flags: review?(arthur.chen)

Updated

4 years ago
Whiteboard: [TD-9530], interaction, [devices-triaged] → [TD-9530], interaction, [devices-triaged], [ucid:BTP20, ft:devices]
Attachment #8346396 - Flags: feedback?(arthur.chen)
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!
Attachment #8346396 - Flags: review?(arthur.chen)
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.:)
Attachment #8346396 - Flags: review?(arthur.chen)
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!
Attachment #8346396 - Flags: review?(arthur.chen)

Updated

4 years ago
Flags: in-moztrap+

Updated

4 years ago
No longer blocks: 949302
Whiteboard: [TD-9530], interaction, [devices-triaged], [ucid:BTP20, ft:devices] → [TD-9530], interaction, [devices-triaged], [ucid:BTP20, 2.0:p2, ft:devices]

Updated

4 years ago
Whiteboard: [TD-9530], interaction, [devices-triaged], [ucid:BTP20, 2.0:p2, ft:devices] → [TD-9530], interaction, [devices-triaged], [ucid:BTP20, 2.0, ft:devices]
(Assignee)

Updated

4 years ago
Depends on: 964146
(Assignee)

Updated

4 years ago
No longer depends on: 964146
(Assignee)

Updated

4 years ago
Depends on: 1003739
After bug 1003739 landed, I will refine the patch here again.
Status: ASSIGNED → NEW
Whiteboard: [TD-9530], interaction, [devices-triaged], [ucid:BTP20, 2.0, ft:devices] → [TD-9530], interaction, [devices-triaged], [ucid:BTP20, 2.0, ft:devices], [p=3]
(Assignee)

Updated

4 years ago
Target Milestone: --- → 2.0 S2 (23may)

Updated

4 years ago
feature-b2g: --- → 2.0
(Assignee)

Updated

4 years ago
Status: NEW → ASSIGNED
Created attachment 8426124 [details] [review]
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.
Attachment #8426124 - Flags: review?(arthur.chen)
Comment on attachment 8346396 [details] [review]
pull request 14598

Per comment 90, obsolete the useless patch for settings app.
Attachment #8346396 - Attachment is obsolete: true
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!
Attachment #8426124 - Flags: review?(arthur.chen)

Updated

4 years ago
Target Milestone: 2.0 S2 (23may) → 2.0 S3 (6june)
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.
Attachment #8426124 - Flags: review?(arthur.chen)
Comment on attachment 8426124 [details] [review]
pull request 19474

r=me, thanks for the effort!
Attachment #8426124 - Flags: review?(arthur.chen) → review+
Since the pr is landed, we can close the issue now.

Gaia/master: 391a06139a379a04fef7cabbd31896a05148c80a
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED

Comment 96

4 years ago
Verified on 
Gaia      a38a6a5c6fabc97dd16d5360632b5ac5c7e06241
Gecko     https://hg.mozilla.org/mozilla-central/rev/951e3a671279
BuildID   20140604160202
Version   32.0a1
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.