832367 - Music app fails to send an .ogg file over bluetooth (to Android phone), and won't explain why

Status: RESOLVED WONTFIX

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

Description

[Daniel Holbert [:dholbert]]

1. Pair another bluetooth device with your B2G device. (I'm using my Nexus 4 android phone)
 2. Open music app, tap the lower-right icon for "albums" view, tap an artist,
     and long-press an audio-file in the final listing.
 3. Tap your other device in the dialog that pops up, and hit OK.

ACTUAL RESULTS: Immediate failure, w/ message "Bluetooth received a file it can not o..."

EXPECTED RESULTS: Transfer should succeed.

If I try to send a photo over bluetooth, w/ the gallery's 'share' button, then _that_ succeeds.  I've only hit this failure w/ the music app.


(Note: I think the error message might be wrong/misleading, too -- I filed bug 832365 on that.)

I'm using an unagi w/ build id 20130116230203.

Comment 1

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

I have got a Nexus 4 and tried, and found what the problem is. Nexus 4 (and Galaxy Nexus as well) with Android 4.2.1 installed would refuse .ogg files. It would send response with error code "Unsupported Media Type (0xCF)" to us and terminate the file transferring process. I pushed a .mp3 file into Unagi and was able to send the mp3 file to Nexus 4 successfully. Daniel, could you please test again with sending non-ogg files?

This is not a severe problem, nevertheless, we should still give Gaia more accurate description about why the transferring failed to not confuse users.

Comment 2

[Daniel Holbert [:dholbert]]

(In reply to Eric Chou [:ericchou] [:echou] from comment #1)
> Daniel, could you
> please test again with sending non-ogg files?

Confirmed -- I can send an mp3 file correctly.

Comment 3

[Daniel Holbert [:dholbert]]

The error message has improved slightly now (clarifying what happened), BTW -- now it says:
>  Bluetooth file transfer failed. Check that the Bluetooth settings are correct
instead of "Bluetooth received a file..." as noted in comment 0.

Still, it has no indication of what went wrong (the other device told us it doesn't support this media type, per comment 1), so I think there's still quite a bit of improvement here and I'm leaving this open.

Comment 4

[amitav.anand]

Issue is reproducible when sending ogg file from ZTE device (Flashed with FireFox 1.3) Nexus 4 (Flashed with Android JB). Sending mp3 file works fine between firefox and android.

Comment 5

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

(In reply to amitav.anand from comment #4)
> Issue is reproducible when sending ogg file from ZTE device (Flashed with
> FireFox 1.3) Nexus 4 (Flashed with Android JB). Sending mp3 file works fine
> between firefox and android.

Different devices may reject different file format which is transferred via Bluetooth. Unfortunately Gecko Bluetooth may be unable to tell the device user about the exact reason of failure. So, I think what we could do is to improve the error message, letting user know possible failure cases in one page.

Actually we have a similar request from Dietrich (bug 949554) for a better "fail to send" erro message. So I think Neo would be the right person to ni?.

Comment 6

[Ben Tian (inactive)]

FYR. Android (Galaxy tab) and Mac OS also fail to send ogg files to Android JB (nexus 7). Galaxy tab shows only "[filename] not sent" as well, while Mac OS tells "The file transfer failed: unsupported item or action."

Comment 7

[Neo Hsieh [:neo]]

I discussed with Ian about this topic, Can we use these six error code ? 
(401.403.406.408.413.415)

Comment 8

[Ben Tian (inactive)]

Neo: Sure.

Ian: To inform gaia of error code, my thought is to carry additional 'errorCode' in system message "bluetooth-opp-transfer-complete" when 'success' is 0, and let gaia filter out undesirable errors. Let me know if you have other suggestions.

Comment 9

[Ben Tian (inactive)]

Attachment: Patch 1 (v1): [gecko] Inform gaia of tranfer error code

Comment 10

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

Attachment: WIP of pull request 15133

This is WIP for feasibility. We still need UX input for the final spec., especially the error message review. The additional error message prompt are as following.

===== Title =====
transferFailed-title=File transfer failed

===== Body =====
transferFailed-unauthorized=Unauthorized. Authorization has been refused for those credentials.
transferFailed-forbidden=Forbidden. The server understood the request, but is refusing to fulfill it.
transferFailed-notAcceptable=Not Acceptable. The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request.
transferFailed-requestTimeout=Request Timeout. The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time.
transferFailed-requestedEntityTooLarge=Requested Entity Too Large. The server is refusing to process a request because the request entity is larger than the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request.
transferFailed-unsupportedMediaType=Unsupported Media Type. The server is refusing to service the request because the entity of the request is in a format not supported by the requested resource for the requested method.
transferFailed-unknownError=Unknown error.

I reference the error message via http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html . I think the description of scenario is needed to overwrite in Bluetooth file transfer error case.

Neo, could you please help to review the error message? I will revise it to reach your final spec. Thanks.
Ben, could you please help to give some feedback for the patch? Thank you.

Comment 11

[Ben Tian (inactive)]

Comment on attachment 8357628 [details] [review]
WIP of pull request 15133

The gaia patch works well with my gecko patch in comment 9.

Comment 12

[Neo Hsieh [:neo]]

Can we just use these simple title string to explain those error ? 

401 Unauthorized
403 Forbidden
406 Not Acceptable
408 Request Timeout
413 Request Entity Too Large
415 Unsupported Media Type

Comment 13

[Ben Tian (inactive)]

Attachment: Patch 1 (v2): [gecko] Inform gaia of tranfer error code

Changes:
- Inform gaia of transfer error code
- Revise some typos

Comment 14

[Ben Tian (inactive)]

(In reply to Neo Hsieh from comment #12)
> Can we just use these simple title string to explain those error ? 
> 
> 401 Unauthorized
> 403 Forbidden
> 406 Not Acceptable
> 408 Request Timeout
> 413 Request Entity Too Large
> 415 Unsupported Media Type
I think more clear and user-friendly error messages are better for users instead of these engineering definitions. But it's up to you regarding UX part. Let me know if you need further details on these errors.

Comment 15

[Neo Hsieh [:neo]]

Actually I only can understand 406.408.415. 

For 
406:Not Acceptable
Target not acceptable your connecting request. Please check target pairing request information

408:Request Timeout
Pairing Waiting time too long to make connection. Please repairing devices.
 
415:Unsupported Media Type
Please try to transfer target supported media type to resolve this problem. 


For 
401:Unauthorized ... I don't know what is the root cause.. 

403:Forbidden ... ?
413: Is the file size too large to transfer ?

Comment 16

[Neo Hsieh [:neo]]

After discuss those error codes with Ben, We need Ben provide whole error codes' root cause and how to resolve those issues. 
Then we can use alert window to inform user and remind them how to fix it.

Comment 17

[Ben Tian (inactive)]

I'll discuss with Eric and provide known error causes and details. ni? myself to remind.

Comment 18

[Neo Hsieh [:neo]]

Comment on attachment 8357628 [details] [review]
WIP of pull request 15133

Hi Ian, I discussed with Ben about this issue. We still need Ben provide whole BT error situations and reasons and how to fix them. So maybe not just those 6 error codes or less than that. Please wait or join our discussion.

Comment 19

[Neo Hsieh [:neo]]

Ben & Ian, Thank you for your help !  :)

Comment 20

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

Comment on attachment 8358279 [details] [diff] [review]
Patch 1 (v2): [gecko] Inform gaia of tranfer error code

Review of attachment 8358279 [details] [diff] [review]:
-----------------------------------------------------------------

Hi Ben, please see my comments below.

::: dom/bluetooth/bluez/BluetoothOppManager.cpp
@@ +1288,5 @@
>    v = mSuccessFlag;
>    parameters.AppendElement(BluetoothNamedValue(name, v));
>  
> +  // Attach error code if transfer failed
> +  if (!mSuccessFlag) {

Not sure if this if-check is really necessary. If we can guarantee the correctness of mTransferErrorCode when mSuccessFlag is true (according to your implementation in Reset(), it should be 0 in this case), then I'd prefer removing this check. Actually you may want to add an assertion like

  MOZ_ASSERT_IF(mSuccessFlag, mTransferErrorCode == 0);

at the beginning of this function.

::: dom/bluetooth/bluez/BluetoothOppManager.h
@@ +172,5 @@
>  
> +   /**
> +    * Indicate the reason of transfer failure
> +    */
> +   uint8_t mTransferErrorCode;

I'm a little bit concerned about the name. It seems to me that mTransferErrorCode should represent a problem related to 'transferring', such as network is not available, packet loss, buffer overflow ... etc. Since this error code we received from remote is defined in OBEX spec, how about just name it mObexError(Response)Code?

Comment 21

[Ben Tian (inactive)]

Neo, the following lists error responses with known causes when sender transfers a file to receiver:
1) Bad Request / Length Required:
     The packet format is invalid.
2) Unauthorized / Forbidden:
     Receiver (user) rejects file transfer. Note FxOS replies 'Unauthorized' while Android replies 'Forbidden'.
3) Unsupported Media Type:
     Receiver rejects file transfer due to unsupported file format.
4) Internal Server Error:
     Receiver fails to receive the file due to internal error.
5) Not Implemented:
     The requested command is not implemented in receiver.

IMO, 2)-4) should have better error messages to inform user. 1) and 5) shouldn't happen if both sender and receiver follow the spec.

Also, do these specific error messages show on sender only or both sender and receiver? If both, the messages may be different based on their respective role.

Comment 22

[Neo Hsieh [:neo]]

Thank you, That's very helpful for me!! 

So we just need to use :

2) Unauthorized / Forbidden:
     Receiver (user) rejects file transfer. Note FxOS replies 'Unauthorized' while Android replies 'Forbidden'.
3) Unsupported Media Type:
     Receiver rejects file transfer due to unsupported file format.
4) Internal Server Error:
     Receiver fails to receive the file due to internal error.

Am I correct ?

Comment 23

[Ben Tian (inactive)]

Yes, you are correct. Please revise the wording to be more informative, and answer my question in comment 21:
> Also, do these specific error messages show on sender only or both sender
> and receiver? If both, the messages may be different based on their
> respective role.

Comment 24

[Ben Tian (inactive)]

Attachment: Patch 1 (v3): [gecko] Inform gaia of tranfer error code

Revise based on reviewer's suggestion.

Comment 25

[Neo Hsieh [:neo]]

Actually we need to inform user which that was be canceled. 

I mean if device A cancel the transferring action, device B should show the reason and tell user how to fix it.
It will not depends on which one is sender or receiver. 

Just like this issue, device B stopped to receive the file but the system not support that media type. Device A should be inform the reason. If device A stopped to send file, then device B should be inform that error caused by device A stopped it.

Comment 26

[Ben Tian (inactive)]

> Just like this issue, device B stopped to receive the file but the system
> not support that media type. Device A should be inform the reason. If device
> A stopped to send file, then device B should be inform that error caused by
> device A stopped it.
I mean, in this case, does device B show error message if it actively rejects device A's request? If so, device B may show 'Reject request for [reason]', whereas device A may show different message 'Request is rejected for [reason]'.

Comment 27

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

Per offline discussion, we need to give more description in unknown error case. There are many use cases fell into this case, including of cancel file transferring, other device(Mac) not turn on Bluetooth.

Comment 28

[BMO Automation]

Firefox OS is not being worked on