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

Status: RESOLVED WONTFIX

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

Description

[Dietrich Ayala (:dietrich)]

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.

Comment 1

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

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.

Comment 3

[Ben Tian (inactive)]

Please refer to bug 949222 comment 6 for device team comment.

ni? UX Neo for error notification flow and message wording.

Comment 4

[Neo Hsieh [:neo]]

Can anyone explain this bug in detail ? Steps or screenshot. Please.

Comment 5

[Neo Hsieh [:neo]]

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

Comment 6

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

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).

Comment 7

[Dietrich Ayala (:dietrich)]

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?

Comment 8

[Eric Chou [:ericchou] [: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.

Comment 9

[Eric Chou [:ericchou] [: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.

Comment 10

[Dietrich Ayala (:dietrich)]

Reminder - I'm talking about when BT is *disabled* on a device that was previously paired. Would need an SDP connection in that case?

Comment 11

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

(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.

Comment 12

[Gregor Wagner [:gwagner]]

Even FxOS experts can't figure out whats going on with the current UI/UX. We need to fix this.

Comment 14

[Tiffanie Shakespeare [:tif]]

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!

Comment 15

[Ben Tian (inactive)]

ni? gaia dev Fred to comment.

Fred, please check comment 14 and let tif know if you need clear UX spec for implementation.

Comment 16

[[e-mail]]

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?

Comment 17

[BMO Automation]

Firefox OS is not being worked on