Description: When a phone is already receiving a file and a 3rd phone attempts to send the receiving phone a file it will not work. but when the 3rd phone sends the file that does not work a banner appears that says a transfer has started. Repro Steps: 1) Update a Flame device to BuildID: 20141008000201 2) Device B sends a file to Device C using NFC 3) Device A sends a file to Device C using NFC 4) Observe notifications that appear on Device A after sending file Actual: A message appear saying the transfer has started Expected: A notification appears saying that the file could not be transferred. Environmental Variables: Device: Flame 2.1 (319mb)(Full Flash) BuildID: 20141008000201 Gaia: d71f8804d7229f4b354259d5d8543c25b4796064 Gecko: 7fa82c9acdf2 Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf Version: 34.0a2 (2.1) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Repro frequency: 100%, etc.) Link to failed test case: https://moztrap.mozilla.org/manage/case/10582/ See attached: video clip(http://youtu.be/NIRs3U9Um6s), logcat

This issue is occurring on 2.2 Flame. Flame 2.2 Master KK (319mb) (Full Flash) Environmental Variables: Device: Flame 2.2 Master BuildID: 20141008065430 Gaia: 0bc74ce502672cf0265b24cf3a25d117c3de5e71 Gecko: dd7637cc42d5 Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf Version: 35.0a1 (2.2 Master) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0 Result: A message appear saying the transfer has started when the transfer does not work. --------------------------------------------------------------------- I was unable to check 2.0 Flame because NFC is not functioning at this time.

I would nominate this to block 2.1. The user will think that the file is being transferred, but the transfer has failed and the user is not informed. NI NFC owner to weigh in on this issue.

In fact, few seconds later, device A would receive a notification "File could not be sent" after trying transfer file. (http://youtu.be/rz00ksMsU3Q) But I think the user experience for device A would be better if device A could get the transfer fail reason at first time. ni? Arno, could device A show the reason of fail transferring file at first time instead of showing "The transfer has started"?

I'm forwarding the ni? to Ian. The status/error notifications are generated by the BluetoothTransfer app. When I was working on this, Ian mentioned that concurrent file transfers are possible but will be handled sequentially. All the NFC layer does is to trigger the file transfers via BluetoothTransfer. I would suspect that the same error happens when you try the same scenario but trigger the transfer manually (via the sharing function and not via a NFC handover).

(In reply to Alison Shiue from comment #3) > In fact, few seconds later, device A would receive a notification "File > could not be sent" after trying transfer file. (http://youtu.be/rz00ksMsU3Q) > But I think the user experience for device A would be better if device A > could get the transfer fail reason at first time. > ni? Arno, could device A show the reason of fail transferring file at first > time instead of showing "The transfer has started"? "The transfer has started" is meaning the sending file request ongoing now(the request is sending out). And we receive system message 'bluetooth-opp-transfer-complete' to give a result of the sending request. We cannot respond the send file error immediately. It's depends on async message from Gecko::Bluetooth. In the message, there are some information about filename, send/receive, successful/unsuccessful. There is no sending file ID, error reason to figure the fail case. But the message will be coming one by one. This is the limitation as far as I know. For the bug here, we have given error message "File could not be sent" after a few seconds. I think it already notifies a user for the before sending request.

From Comment 5 Ian said this is the limitation on the BT side, so mark this as WONTFIX.