Closed Bug 949554 Opened 6 years ago Closed 2 years ago

Bluetooth sharing UI makes laptop seem to be ok to send file, but laptop's Bluetooth is disabled

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(tracking-b2g:backlog)

RESOLVED WONTFIX
tracking-b2g backlog

People

(Reporter: dietrich, Unassigned)

References

Details

(Keywords: foxfood, Whiteboard: [papercuts])

I had to wait until file sending failed, wondering what happened, and only then noticed that Bluetooth was disabled on the laptop.

If cannot detect the paired device, we should communicate to the user that the device is not available for sending files to.

Or if that's not possible, once we do finally know that we can't connect to the device, we should give a better message to the user.
Whiteboard: [papercuts]
OS: Mac OS X → Gonk (Firefox OS)
Hardware: x86 → ARM
It's not a blocking issue. But it could be an improving user story for Bluetooth file sending. Looping device team devs and UX here.
Duplicate of this bug: 949222
Please refer to bug 949222 comment 6 for device team comment.

ni? UX Neo for error notification flow and message wording.
Flags: needinfo?(nhsieh)
Can anyone explain this bug in detail ? Steps or screenshot. Please.
Flags: needinfo?(nhsieh)
Hi Dietrich Ayala, I just discussed this bug with Ben, As far as I know the limitation of this situations is we can not get any imformation from hardware. So I can't tell user what happend. Maybe cause by laptop battery running out, file error, user move device too far, detect virus or like your case. So I suggest that keep this notification until we can get exactly error code from Gecko. Thanks
See Also: → 832367
Quick note: bug 832637 is a bug a little similar to this (needs a better error message when the remote device rejects the file transfer request).
Thanks Neo and Eric!

Eric, can we tell on our end that we're not even able to *try* to connect to the previously-paired laptop?

It seems like we should be able to make that distinction, and provide that level of error detail to Web content layer.

Should I file a separate bug for that lower-level change or can do it here?
Flags: needinfo?(echou)
(In reply to Eric Chou [:ericchou] [:echou] from comment #6)
> Quick note: bug 832637 is a bug a little similar to this (needs a better
> error message when the remote device rejects the file transfer request).

Oops, typo. Should be bug 832367.
Flags: needinfo?(echou)
(In reply to Dietrich Ayala (:dietrich) from comment #7)
> Thanks Neo and Eric!
> 
> Eric, can we tell on our end that we're not even able to *try* to connect to
> the previously-paired laptop?
> 
> It seems like we should be able to make that distinction, and provide that
> level of error detail to Web content layer.
> 

Yes, we can do that. However the operation "check if the service is provided on the remote device" may take time. A Bluetooth SDP connection would be needed, so it's a kind of tradeoff between 'faster response time if the remote device has that service' and 'more accurate error message if the target service is not registered to the remote device'. I'm fine with both but I'm prone to pick your 'ask before connect' solution. I think Neo is the best person to make the final decision.

> Should I file a separate bug for that lower-level change or can do it here?

Using this should be fine.
Reminder - I'm talking about when BT is *disabled* on a device that was previously paired. Would need an SDP connection in that case?
(In reply to Dietrich Ayala (:dietrich) from comment #10)
> Reminder - I'm talking about when BT is *disabled* on a device that was
> previously paired. Would need an SDP connection in that case?

No, the only thing we have to do to make sure if the remote device is enabled or not is trying to establish an ACL connection. This process is called 'Page' in Bluetooth, and the page process would take several seconds until 'page timeout'. Page timeout is configurable in main.conf of BlueZ stack which has to be set during compile time. Currently we set 5 secs (Default BlueZ is 10).

Therfore, back to your original description, "If cannot detect the paired device, we should communicate to the user that the device is not available for sending files to." -- Yes we can, just needs a few seconds, and I guess you would be more interested in "can we know that the remote device is not on immediately". In my opinion, I believe most of people who got the error message when they are using device A sending files to device B via Bluetooth, would first check if Bluetooth is enabled on device B because it's quite intuitive. However they may not be aware of that they also have to enable file sharing service on the device. I think that's the point we can improve.
Even FxOS experts can't figure out whats going on with the current UI/UX. We need to fix this.
Keywords: foxfood
Flags: needinfo?(firefoxos-ux-bugzilla)
Duplicate of this bug: 1223329
From UX triage:

The current is super confusing and we should let users know when the paired is not available for bluetooth transfers. Let's add a second line of text that says "Not Connected". The whole list item should be disabled - tapping should not start a transfer until the two devices are connected.

Thanks for pinging the UX team!
Flags: needinfo?(firefoxos-ux-bugzilla)
ni? gaia dev Fred to comment.

Fred, please check comment 14 and let tif know if you need clear UX spec for implementation.
Flags: needinfo?(gasolin)
Flags: needinfo?(gasolin) → needinfo?(gasolin)
I'm not pretty sure which screen should be improved with above messages.

Jack could you help check comment 14 and make a UI spec?
Flags: needinfo?(gasolin) → needinfo?(jalin)
Flags: needinfo?(jalin)
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.