All users were logged out of Bugzilla on October 13th, 2018

[Bluetooth][Settings][User Story] A timer to control the property visible while turning it on.

RESOLVED WONTFIX

Status

RESOLVED WONTFIX
4 years ago
8 months ago

People

(Reporter: iliu, Unassigned)

Tracking

unspecified
x86
Mac OS X
Dependency tree / graph

Firefox Tracking Flags

(feature-b2g:3.0?)

Details

Attachments

(3 attachments, 1 obsolete attachment)

STR:
1. Turn on Bluetooth
2. Turn visible on

Expected:
There is a timer to count remaining time. Then, turn visible off automatically.

Updated

4 years ago
Duplicate of this bug: 1134244

Updated

4 years ago
feature-b2g: --- → 3.0?

Comment 2

4 years ago
Ian, does this bug require gecko change?
Flags: needinfo?(iliu)
Ben, 

No need any gecko change here. 

AFAIK, the default value of adapter.discoverable is false(if I misunderstand, please correct me). And Gaia shows the visible status corresponding to the property while Settings::Bluetooth is able to get default adapter in init state. In the other side, the user story also has default value 'false'. According to the above conditions, visible state would be 'false' while Bluetooth just be turned from OFF to ON. As our expected result with bug 1134244, comment 2.
Flags: needinfo?(iliu)

Comment 4

4 years ago
Got it. Set component as Gaia::Settings to be clearer.
Component: Bluetooth → Gaia::Settings
(Reporter)

Updated

4 years ago
See Also: → bug 1144532

Comment 5

4 years ago
Created attachment 8595211 [details]
[2.2 Settings] Bluetooth v1.2.pdf

Hi Ian,

Please see attached for the latest BT spec, thanks =)

Comment 6

4 years ago
Created attachment 8596318 [details]
[Settings] Bluetooth v1.21.pdf

Hi Ian,
See attached for updated spec (error handling added). Thanks!
Attachment #8595211 - Attachment is obsolete: true

Comment 7

4 years ago
Hi Helen and Przemek,

I got a visual question for you =) 

See attachment 8596318 [details] on p.14 screen 3 (rename device - error), when user enters more than 20 characters in text field, a warning message about exceeding max length will appear and the "ok" button on header would become non-tappable. What is the correct visual style for this non-tappable state? Right now I have it at lower opacity. 

Another example for this can be found in SIM manager -> SIM security -> enable SIM pin and go to create SIM PIN page (notice the "done" button isn't tappable when PIN is not valid). But the styling here is different, so I need your help on this, let me know, thanks!
Flags: needinfo?(pabratowski)
Flags: needinfo?(hhuang)
You are correct Jenny, reducing the opacity of the "ok" in the correct visual behavior for this case. I would double check with Harly to make sure that the IxD is also correct for this specific case, but it looks good to me.
Flags: needinfo?(pabratowski) → needinfo?(hhsu)

Comment 9

4 years ago
Hi Przemek, Jenny has asked me on the issue earlier this week. For IxD part I only defined that there should be a disable state when the button on the header is not tappable until user has fulfilled the necessary requirements. 

That's why I told Jenny to ask you for help because we have searched for visual pattern for disable button on the header in all of the available documents and there doesn't seem to be one. 

Jenny, it would be great if we can open a new bug for the SIM manager and have devs fix the done button to align with the conclusion here. Thanks :)
Flags: needinfo?(hhsu)
Agree with Przemek, as I know, generally we use opacity for disable state, like switch button in Settings. So I think it will be like setting the non-tappable button to 50% opacity. Let me know if any visual support is needed!
Flags: needinfo?(hhuang)
Thanks for Jenny's update soon. The spec. has been explicit enough to perform.
Status: NEW → ASSIGNED
I believe we had to drop the opacity of 'ok' all the way down to 20% when we did this before, at 50% people still thought they could press it.
Hi Helen,

Per offline discussion with Jenny, there are many different styles for 'explanation' in Settings app now. We feel a little bit confused to give CSS style. So we create a meta bug 1159147 to figure out these inconsistent problem in the long term. 

For this bug, in the spec. page 14(3. Rename device), we still need your help to give style definition. Thanks.
====================================================================
Device name too long (max 20 characters).
This name will appear in other devices when your device is visible.
====================================================================
Flags: needinfo?(hhuang)
Created attachment 8599203 [details] [review]
[gaia] ian-liu:bluetooth/bug1121913_user_story/display_remaining_timeout_of_bluetooth_visibility > mozilla-b2g:master
Comment on attachment 8599203 [details] [review]
[gaia] ian-liu:bluetooth/bug1121913_user_story/display_remaining_timeout_of_bluetooth_visibility > mozilla-b2g:master

Here is an work in process patch to implement this user story. It's able to complete the major change. But still need UX/VD to feedback for fine-tune the style in detail. 

Helen and Jenny, I will show you the work if you're available.

Ben, Since I work on this patch, I see one use case let us missed to set discoverable 'false'. We should call |adapter.setDiscoverableTimeout(duration)| before Gaia do |adapter.setDiscoverable(true)|. Because Settings app might be killed while the |adapter.setDiscoverable(false)| timeout has not been executed. In the case, Bluetooth is still discoverable until a user go into Settings::Bluetooth panel.

In order to overcome the problem, I implement |adapter.setDiscoverable(false)| timeout in system app. It must do |adapter.setDiscoverable(false)| until timeout. But the un-launched Settings app won't know when System app has set the timeout. It will let the remaining time of discoverable property incorrect. So I have to create a settings key 'bluetooth.discoverable.disableTimestamp' for |addObserver()| in Settings app.

All of above works is hacking via mozSettings key. I see |adapter.setDiscoverableTimeout(duration)| API is not defined in Bluetooth API v2. Could we retain it or have a API |adapter.setDiscoverable(true, duration[1])|? It will help all these Gaia work stay in Settings app only. Thanks.

[1]: An optional arg.
Attachment #8599203 - Flags: feedback?(jelee)
Attachment #8599203 - Flags: feedback?(hhuang)
Attachment #8599203 - Flags: feedback?(btian)

Comment 16

4 years ago
Comment on attachment 8599203 [details] [review]
[gaia] ian-liu:bluetooth/bug1121913_user_story/display_remaining_timeout_of_bluetooth_visibility > mozilla-b2g:master

Jocelyn will check whether bluedroid supports discoverable timeout setting. ni? her instead.

Ian, meanwhile please confirm w/ Jenny which of following UX behaviors is desired:
1) When Settings app is killed, discoverable timer keeps running and remaining time shows when Settings app restarts.
2) When Settings app is killed, discoverable becomes false and timer resets when Settings app restarts.
3) When Settings app is killed, discoverable becomes false until user sets discoverable as true again.
Flags: needinfo?(joliu)
Attachment #8599203 - Flags: feedback?(btian)

Comment 17

4 years ago
Hi all,

I've tried to use |bt_interface_t.set_adapter_property()| to set |BT_PROPERTY_ADAPTER_DISCOVERY_TIMEOUT| property with a timeout value on flame-kk, but nothing happens when the timeout passed. The discoverable state keeps the same no matter the timeout value is set or not. It seems the timeout function is not completed in current bluedroid.

Remove ni? of Jocelyn because the information is provided here.
Flags: needinfo?(joliu)
(In reply to Ben Tian [:btian] from comment #16)
> Comment on attachment 8599203 [details] [review]
> [gaia]
> ian-liu:bluetooth/bug1121913_user_story/
> display_remaining_timeout_of_bluetooth_visibility > mozilla-b2g:master
> 
> Jocelyn will check whether bluedroid supports discoverable timeout setting.
> ni? her instead.
> 
> Ian, meanwhile please confirm w/ Jenny which of following UX behaviors is
> desired:
> 1) When Settings app is killed, discoverable timer keeps running and
> remaining time shows when Settings app restarts.
> 2) When Settings app is killed, discoverable becomes false and timer resets
> when Settings app restarts.
> 3) When Settings app is killed, discoverable becomes false until user sets
> discoverable as true again.

Thanks for Ben's description in detail. Per spec. definition in page 13, step 3., UX behavior should be 3). Jenny, If I misunderstand, please correct me here!

================================================================================================
- Keep the count down timer as long as Settings is running either in foreground or in background. If Settings app is killed, visible to all will be set to off.
================================================================================================

Comment 19

4 years ago
(In reply to Ian Liu [:ianliu] from comment #18)
> > 
> > Ian, meanwhile please confirm w/ Jenny which of following UX behaviors is
> > desired:
> > 1) When Settings app is killed, discoverable timer keeps running and
> > remaining time shows when Settings app restarts.
> > 2) When Settings app is killed, discoverable becomes false and timer resets
> > when Settings app restarts.
> > 3) When Settings app is killed, discoverable becomes false until user sets
> > discoverable as true again.
> 
> Thanks for Ben's description in detail. Per spec. definition in page 13,
> step 3., UX behavior should be 3). Jenny, If I misunderstand, please correct
> me here!
> 
> =============================================================================
> ===================
> - Keep the count down timer as long as Settings is running either in
> foreground or in background. If Settings app is killed, visible to all will
> be set to off.
> =============================================================================
> ===================

Yup you are right! 
(Technically 1 would make most sense since BT and Settings are two different apps, but to regular users, BT should be perceived as part of Settings, hence 3 is the proper behavior.)
Per offline discussion with Gecko::Bluetooth devs and my WIP, I give a summary for the feasibility of 1) and 3).

3) When Settings app is killed, discoverable becomes false until user sets discoverable as true again.(the proper hehavior)

The limitation is no entry point to set discoverable to false while Settings app be closed(or killed). Because Gaia app won't be notified while it is closed. And I have try the event 'window.onunload'. It still does not work now(known issue mentioned from Alive).

In the view point of System app, it's not a good way to check/set discoverable to false in System app while Settings app is closed every time. This is a hack solution here. Therefore, I would like to request some helps to set discoverable to false from platform side.

 
1) When Settings app is killed, discoverable timer keeps running and remaining time shows when Settings app restarts.(most sense behavior)

Per comment 15 with WIP, have to create a mozSettings key 'bluetooth.discoverable.disableTimestamp' for recording the stamp from System app to Settings app. Because we always rely on System app for settings discoverable. Settings app cannot ensure to set discoverable property back to false.

In this case, Alive and I would like to request platform to set discoverable false while it's timeout. At the same time, Settings app could use |asyncStorage| instead of mozSettings key for recording time stamp. If we can have a API |adapter.setDiscoverableTimeout(duration)| as API v1, it's good to handle the user story.


Whether the limitation 1) or 3), there is no app life cycle to let Gaia app to do something while Gaia app is closed. Or a background service to the process which is executed in app closed.

Ni Ben for above discussion. Thanks.
Flags: needinfo?(btian)
Created attachment 8600780 [details]
VsD_Specifcation_Bluetooth.pdf

Updated the visual spec which is based on page 13 and 14 in the ux document, let me know if any question. Thanks!
Flags: needinfo?(hhuang)
Comment on attachment 8599203 [details] [review]
[gaia] ian-liu:bluetooth/bug1121913_user_story/display_remaining_timeout_of_bluetooth_visibility > mozilla-b2g:master

Per visual spec. updated in comment 21, clean up the feedback request. I will update the patch according to the visual.
Attachment #8599203 - Flags: feedback?(jelee)
Attachment #8599203 - Flags: feedback?(hhuang)
Per offline discussion with Jenny, Ben, and Arthur, we have a long discussion for following items.

* Gaia has no suitable method to set discoverable off while Settings app is closed/killed.
* Allow 3rd app to set discoverable on/off.
* Shall we provide remaining discoverable time from API side?

I remember Jenny has different view point for set discoverable on/off while Settings app is closed. Ni for confirmation here.
Status: ASSIGNED → NEW
Flags: needinfo?(jelee)

Comment 24

4 years ago
Hello Ian,

A few points:
- Allow 3rd app to set discoverable on/off.
- Discoverable count down timer is global, any app that has access to BT discoverable should read the same remaining time. 
- If there's no way to set discoverable off when Settings app is closed/killed, I think it's fine to just keep the timer count down.     

Thanks!
Flags: needinfo?(jelee)
Note: I remember the discussion is still at timer implementation from platform investigation.
Assignee: iliu → nobody
Blocks: 1134244

Updated

3 years ago
Duplicate of this bug: 796791

Comment 27

3 years ago
Clear my ni? since we don't add any new bluetooth feature now.
Flags: needinfo?(btian)

Comment 28

8 months ago
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 8 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.