998175 - [NFC] Receive Image/video file by NFC from device A, while still receiving file from another device B through BT

Status: VERIFIED FIXED

(Firefox OS Graveyard :: NFC, defect)

Description

[Alison Shiue]

Attachment: Device A's debug log

Using most up-to-date pvt build (2014/4/14) to test
Two phones(Device A, Device B) with NFC and BT, 1 laptop with BT

STR:
1. Enable NFC in settings on both phones
2. Device A receiving video from laptop via BT
3. Touch two phones together
4. Swipe screen on Device B to share an image to Device A (laptop still transfer file)

Expected result:
Device A receive image shared by Device B and video shared by laptop

Actual result:
Device A could not receive image from Device B

Comment 1

[Alison Shiue]

I'm not sure if this issue related to NFC or bluetooth, please correct me if exist any misunderstanding.

Comment 2

[Ken Chang[:kenkai]]

John, I wonder if you could do analysis for this bug first.

Comment 3

[John Hu [:johnhu][:johu][:醬糊小弟]]

From the description of this bug, it needs to check if the Device B sends the file out. It may help if we got the error messages of device A and B and logcat of them.

If file sends but device A cannot receive or save it (device A shows an error message and device B shows an error message), it is bluetooth app's problem.

If the Device B doesn't send the file out (device B shows an error message but device A doesn't), this may need to check [1] is called. If it is called, we may need to check the underlying NFC or BT module. If it is not called, it may be gallery's issue.

So, more information may speed up the analysis.

[1] https://github.com/mozilla-b2g/gaia/blob/a79a34f8114f5804f363685d717734c383f0d8ab/apps/gallery/js/gallery.js#L741

Comment 4

[John Hu [:johnhu][:johu][:醬糊小弟]]

ashiue,

(followed by comment 3)

Is the video file sent by laptop already received by Device A? I mean the BT transferring is finished or not.

If it is still under transferring, we may need to ask BT team to check if our device support two simultaneously file transfers.

Comment 5

[Alison Shiue]

No, in this test case, the video file sent by laptop is still transferring when Device B try to share file to Device A.

Comment 6

[Ken Chang[:kenkai]]

(In reply to John Hu [:johnhu][:johu][:醬糊小弟] from comment #4)
> ashiue,
> 
> (followed by comment 3)
> 
> Is the video file sent by laptop already received by Device A? I mean the BT
> transferring is finished or not.
> 
> If it is still under transferring, we may need to ask BT team to check if
> our device support two simultaneously file transfers.
Yes, you are right. It seems a BT limit.  ni?ben.
Can BT support 2 transfers simultaneously.

Comment 7

[Ben Tian (inactive)]

(In reply to Ken Chang[:ken] from comment #6)
> Yes, you are right. It seems a BT limit.  ni?ben.
> Can BT support 2 transfers simultaneously.
No, BT doesn't support simultaneous file receiving. For simultaneous file sending, BT queues those files to send them one-by-one.

Comment 8

[Ken Chang[:kenkai]]

I wonder if NFC manger need to reply an error message to notify Device B that handover is impossible in this condition.

Comment 9

[Garner Lee]

Arno, is there an error code or message to handle in handover manager (or bluetooth)?

Comment 10

[arno]

I use BluetoothTransfer.sendFile() for outgoing file transfers. According to comment 7, multiple sends are not a problem. However, there is a problem when the transfer is finished. Right now BluetoothTransfer informs the NFCHandoverManager once a file transfer is completed:
https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/bluetooth_transfer.js#L421
In NfcHandoverManager I then call the onerror/onsuccess of the originating DOMRequest. From what I understand now, it might be possible that the call done in L421 of BluetoothTransfer might not belong to the file transfer that was initiated by the NFC handover.

Ian: can you please confirm that this is a problem? If so, how do you propose to fix this? Is there a notion of an ID or session in BluetoothTransfer.sendFile() I can use to determine if the transfer completed belongs to NFC handover?

Comment 11

[Ken Chang[:kenkai]]

Please this into backlog.

Comment 12

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

(In reply to arno from comment #10)
> I use BluetoothTransfer.sendFile() for outgoing file transfers. According to
> comment 7, multiple sends are not a problem. However, there is a problem
> when the transfer is finished. Right now BluetoothTransfer informs the
> NFCHandoverManager once a file transfer is completed:
> https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/
> bluetooth_transfer.js#L421
> In NfcHandoverManager I then call the onerror/onsuccess of the originating
> DOMRequest. From what I understand now, it might be possible that the call
> done in L421 of BluetoothTransfer might not belong to the file transfer that
> was initiated by the NFC handover.
> 
Hi Arno, yes. This is the root cause here. 

* Desktop's sending file(s) is/are not transferred completely yet.(The files transferring request is not fired via NFCManager.)
* We just use "NfcHandoverManager.isHandoverInProgress()" to identify every completed event.
* NFCManager "doFileTransfer()" while there is an unfinished file which is fired via other module(not NFC).

If the procedure meet above items, the issue here will be reproduced.

> Ian: can you please confirm that this is a problem? If so, how do you
> propose to fix this? Is there a notion of an ID or session in
> BluetoothTransfer.sendFile() I can use to determine if the transfer
> completed belongs to NFC handover?

I would like to suggest that we could add a property "NfcSendFileRequest" in "sendingFilesSchedule".(https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/bluetooth_transfer.js#L283).(Maybe you could have a better naming of the property.) Then, we can check the property exist or not via "this._sendingFilesQueue[0];" in scoop "NfcHandoverManager.isHandoverInProgress()"(https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/bluetooth_transfer.js#L420).

Comment 13

[arno]

Ian: I'm afraid we need to discuss this a little more. First of all, NfcHandoverManager currently does not handle multiple simultaneous file transfers. I'm thinking of having BluetoothTransfer.sendFile() return an id that will also be passed to NfcHandoverManager.transferComplete/isHandoverInProgress(). This way I can handle several file transfers and I can also recognize NFC initiated outgoing transfers. I would attach the id to sendingFileSchedule. What do you think of this idea?

However, even with this solution there is another problem: according to bug 1002304 the state of the BT adapter needs to be restored after a file transfer. Right now I do this in NfcHandoverManager.transferComplete(). Having sendFile() return an id will not help here, because for incoming file transfers this function is not called. In essence, I need to associate the outgoing Handover Select with a transferComplete() that will come later. To be honest, I have no idea right now how to accomplish this. When BluetoothTransfer handles an incoming file transfer, how can it know that the sender did so in response of a handover request? I could tell BluetoothTransfer the MAC address of a device that will soon initiate a file transfer, but even then there might be a race condition if that device sends two files.

Sorry for the lengthy comment. A whiteboard with a face-to-face discussion would be more appropriate.

Comment 14

[Ken Chang[:kenkai]]

Maybe, we don't need to try to send files simultaneously.
I wonder if we could just have a toaster notification when users try to send files simultaneously.

Comment 15

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

(In reply to arno from comment #13)
> Ian: I'm afraid we need to discuss this a little more. First of all,
> NfcHandoverManager currently does not handle multiple simultaneous file
> transfers. I'm thinking of having BluetoothTransfer.sendFile() return an id
> that will also be passed to
> NfcHandoverManager.transferComplete/isHandoverInProgress(). This way I can
> handle several file transfers and I can also recognize NFC initiated
> outgoing transfers. I would attach the id to sendingFileSchedule. What do
> you think of this idea?
> 
I agree that we(bluetooth_transfer.js) could return an id for NFCHandoverManager to identify several files transfer. 

> However, even with this solution there is another problem: according to bug
> 1002304 the state of the BT adapter needs to be restored after a file
I here from Ben, sometimes, there are error message(file transfer failed) while the file was transferred completely and successfully in NFC handover. If the issue is existed, please file a bug for follow up patch. Thanks.

> transfer. Right now I do this in NfcHandoverManager.transferComplete().
> Having sendFile() return an id will not help here, because for incoming file
> transfers this function is not called. In essence, I need to associate the
> outgoing Handover Select with a transferComplete() that will come later. To
> be honest, I have no idea right now how to accomplish this. When
> BluetoothTransfer handles an incoming file transfer, how can it know that
> the sender did so in response of a handover request? I could tell
Yes, I think Gaia does have enough information for the race condition. Even if we have a global flag, we don't know the incoming file which is triggered via NFC/Non-NFC in Bluetooth API. Somehow, the id of file transfer is necessary. And the id or transfer information might be exposed in Bluetooth API('bluetooth-opp-receiving-file-confirmation', 'bluetooth-opp-transfer-complete') too. It will need some discussion here. 

Eric and Ben, do you have any idea for the race condition? And is it possible and reasonable for providing the information(NFC/Non-NFC) while an incoming file request/completely via Bluetooth? I think that Gaia is not able to identify the race condition.

> BluetoothTransfer the MAC address of a device that will soon initiate a file
> transfer, but even then there might be a race condition if that device sends
> two files.
Agree, address is not enough for identification of the race condition.

> 
> Sorry for the lengthy comment. A whiteboard with a face-to-face discussion
> would be more appropriate.

Comment 16

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

(In reply to Ken Chang[:ken] from comment #14)
> Maybe, we don't need to try to send files simultaneously.
> I wonder if we could just have a toaster notification when users try to send
> files simultaneously.

This is another solution to avoid race condition, I think. But a user have to wait files transferring task completely. Shell we need UX comment here?

Comment 17

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

I just make a experience on Android with NFC module. The file transfer layout of notification center are different for the two transferring module(NFC/Non-NFC). If there is an incoming files via NFC after non-NFC file transferring in progress, the file transferring of NFC won't be transferred successfully. This might be a bug. And the UI might be for reference.

Comment 18

[arno]

To make matters worse, the race condition could also result in a potential security problem: for incoming file transfers that were triggered by NFC we currently bypass the confirmation dialog:
https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/bluetooth_transfer.js#L133
Because of the race condition it might be possible that an incoming file transfer is implicitly accepted that was not initiated by NFC.

Comment 19

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

ni? to Juwei.
Per the question raised in Comment 14, do we expect simultaneous transfer?
Comment 17 shows the behavior of android system as reference.

Comment 20

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

(In reply to arno from comment #18)
> To make matters worse, the race condition could also result in a potential
> security problem: for incoming file transfers that were triggered by NFC we
> currently bypass the confirmation dialog:
> https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/
> bluetooth_transfer.js#L133
> Because of the race condition it might be possible that an incoming file
> transfer is implicitly accepted that was not initiated by NFC.

Per offline discussion with Ben, Gaia::BluetoothTransfer could provide a status 'transferring' while it's handling a transferring task(sending/receiving). The status 'transferring' means that Gecko::Bluetooth fire event between 'bluetooth-opp-update-start' to 'bluetooth-opp-update-progress'. Then, NfcHandoverManager could check each incoming file transfers until a transferring task completely. But, if there are more than two outgoing/incoming files in queue before Nfc confirms transfer with other device, the checking rule will be broken. Even if we use address and filename for checking incoming files for NFC, these info is not enough to ensure each transferring task without an id.

Comment 21

[Juwei Huang[:juwei]]

I'm okay with queuing the files when another BT transfer is happening. They don't need to happen simultaneously as long as we have a hint to tell users that their file transfer is in progress and they know where to check the status.

Following BT's behaviour, all the queuing files would be displayed on the notification tray. So I suppose in this case, the received image/ video is also queuing under the file transferred by laptop. 

So the flow would be:

[Sender]
1. Tap phone together
2. UI shrink, swipe up to share image/video
3. UI back to normal , a toast states "Sending file"
4. Once file transfer complete, a toast states "File transfer complete"

[Receiver]
1. Tap phone together
2. A notification states "Receiving file..."
3. Tap on the notification or drag down notification tray
4. Check the queuing status

Comment 22

[Ken Chang[:kenkai]]

I think Arno is working on this.

Comment 23

[arno]

Ian: I've created a patch that should fix all issues that can be fixed. There is still a race condition for multiple incoming file requests as discussed in earlier comments, but since NFC and BT do not share any context during a handover, there is no way to avoid this. I've made changes to BluetoothTransfer and I would like your feedback on my changes. Since files are transferred in FIFO order, I didn't need an ID. Instead I keep a flag in _sendingFilesQueue that allows me to recognize a sendFile() that was done via NFC.

https://github.com/svic/gaia/commit/73d503c8f60f17a1f277587a54840691fe5080ba

Comment 24

[arno]

Attachment: Properly handle concurrent file transfers

Comment 25

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

(In reply to arno from comment #23)
> Ian: I've created a patch that should fix all issues that can be fixed.
> There is still a race condition for multiple incoming file requests as
> discussed in earlier comments, but since NFC and BT do not share any context
> during a handover, there is no way to avoid this. I've made changes to
> BluetoothTransfer and I would like your feedback on my changes. Since files
> are transferred in FIFO order, I didn't need an ID. Instead I keep a flag in
> _sendingFilesQueue that allows me to recognize a sendFile() that was done
> via NFC.
> 
> https://github.com/svic/gaia/commit/73d503c8f60f17a1f277587a54840691fe5080ba

It looks good for me with address on GitHub. Feedback+ in side of BluetoothTransfer. Please be careful for auto-restore (enable/disable) Bluetooth status after NFC files sharing completely. Thanks.

Comment 26

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 8426686 [details] [review]
Properly handle concurrent file transfers

We have bluetooth_transfer_test and nfc_handover_manager_test so I expect we have tests for changes made.

Comment 27

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

Arno, Bug 987039 is working on unit test for cover all of bluetooth_transfer.js. Please take a look the change. In part of BluetoothTransfer, I would like to suggest you add the new test after Bug 987039 landed.

Comment 28

[Kamil Leszczuk [:kamituel]]

Attachment: Pull request

Arno has prepared handover manager test cases, as requested. He's out for a couple of days, and to not delay this bug, he asked me to rebase his branch onto latest master.

Comment 29

[Greg Weng [:snowmantw][:gweng][:λ]]

Set feedback to Ian because I'm not intimate with Bluetooth component.

Comment 30

[Greg Weng [:snowmantw][:gweng][:λ]]

Comment on attachment 8433088 [details] [review]
Pull request

It's fine for me except the flag name seems a little confused. Maybe you can explain it on GitHub and I can set the review+.

Comment 31

[arno]

(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #30)
> It's fine for me except the flag name seems a little confused. Maybe you can
> explain it on GitHub and I can set the review+.

What exactly is your question? Which 'flag' are you referring to?

Comment 32

[arno]

(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #30)
> It's fine for me except the flag name seems a little confused. Maybe you can
> explain it on GitHub and I can set the review+.

Never mind. I guess you were referring to the two questions you left on Github. I just replied to both. Let me know if you have any other questions.

Comment 33

[Greg Weng [:snowmantw][:gweng][:λ]]

OK, I've read the comment and it's fine. Please wait Ian to give his feedback.

Comment 34

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

Comment on attachment 8433088 [details] [review]
Pull request

Arno, I leave some comment on GitHub. Please take a look in unit test after function refined. I'm happy to have a second feedback/review in part of bluetooth_transfer.js when the patch is udpated. Thanks.

Comment 35

[Dietrich Ayala (:dietrich)]

Blocks a 2.0 blocker, requesting blocking.

Comment 36

[Dietrich Ayala (:dietrich)]

Hi Arno, are you going to be able to update the PR soon? If not, we can find someone else to finish it. Thanks!

Comment 39

[arno]

(In reply to Dietrich Ayala (:dietrich) from comment #36)
> Hi Arno, are you going to be able to update the PR soon? If not, we can find
> someone else to finish it. Thanks!

Sorry for the delay. Kamil is working on the patch.

Comment 40

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

setting target milestone to S5 because we would prefer not to put blockers to last sprint before FC.
let me know if it's doesn't work.

Comment 41

[Kamil Leszczuk [:kamituel]]

Comment on attachment 8433088 [details] [review]
Pull request

Hi Ian, we've fixed all your comments and added some additional test case to check whether BluetoothTransfer.transferComplete() calls NfcHandoverManager.transferComplete() with valid arguments.

Comment 42

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

Comment on attachment 8433088 [details] [review]
Pull request

Kamil, in part of Bluetooth file transfer is good for me. Still address a small nit on GitHub. But I cannot share file through NFC on reference phone Flame. In other words, I'm not able to help to verify the patch manually. Could you please take care manual test here? Thanks.

Comment 43

[Ken Chang[:kenkai]]

Kamil, do you also help bug 1009470?

Comment 44

[Kamil Leszczuk [:kamituel]]

Ken, it's up to Arno to decide. If he's unable to work on 1009470, I'll be happy to help.

As for this bug, I'll try to manually test it today. @Ian, will doing scenario from comment 1 be enough?

Comment 45

[arno]

(In reply to Kamil Leszczuk [:kamituel] from comment #44)
> Ken, it's up to Arno to decide. If he's unable to work on 1009470, I'll be
> happy to help.
> 
> As for this bug, I'll try to manually test it today. @Ian, will doing
> scenario from comment 1 be enough?

Bug 1009470 should be marked a duplicate of this one. I did submit a one-line patch for Bug 1009470 but the problem should also be fixed by this bug. I will be at the office tomorrow and plan to test this patch on Flame to see what problems Ian encountered.

Comment 47

[arno]

Some updates: I did some testing on Flame and the NDEF exchange during P2P is OK. I found two problems: in one case onerror() for a sendNDEF() is not called (I opened bug 1033067). The other problem is with the BT file transfer that does not seem to work. For the latter I will leave a NI with Eric.

Comment 48

[arno]

Eric: I tested this patch on a Flame device and the NDEF messages are exchanged correctly. However, the BT file transfer is not happening in all cases. Sending a file to the Flame device never works (Android reports "Beam aborted"). For out-going file transfers (Flame being the sender) it sometimes aborts in the middle of the transfer. Since the NDEF messages are exchanged correctly, the problem seems to be with the BT layer.

Comment 49

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

Hi Arno,

(In reply to arno from comment #48)
> Eric: I tested this patch on a Flame device and the NDEF messages are
> exchanged correctly. However, the BT file transfer is not happening in all
> cases. Sending a file to the Flame device never works (Android reports "Beam
> aborted"). For out-going file transfers (Flame being the sender) it
> sometimes aborts in the middle of the transfer. Since the NDEF messages are
> exchanged correctly, the problem seems to be with the BT layer.

It seems to be bug 1032088. If you have ever full flashed Flame through our pvt tool, some configuration files for Bluetooth stack might be missing.

Arno, could you assist with confirming one thing? If the Bluetooth device name of your Flame shown on Settings/Bluetooth is 'BlueZ' but not 'Flame', then it means you hit the bug. Or you can just do

  adb shell
  cd /system/etc/bluetooth

if there is only one file (stack.conf) in the folder, then you hit the bug.

Temp solution:

(1) Go to B2G root folder
(2) cd system/bluetooth/data
(3) adb remount
(4) adb push . /system/etc/bluetooth
(5) Reboot

Would you please give it a try?

Comment 50

[arno]

Eric,

> Arno, could you assist with confirming one thing? If the Bluetooth device
> name of your Flame shown on Settings/Bluetooth is 'BlueZ' but not 'Flame',
> then it means you hit the bug.

yes, I see the name 'BlueZ', so I hit the bug you mentioned. I will follow your hot-fix and report back. Thanks for your prompt help!

Comment 51

[arno]

Ian: I assume you knew about the problem that Eric mentioned in comment 49? I just tested the patch on my Flame device (I rebased to latest master) and the tests I tried were all working fine (including a simultaneous over-cross transfer between Fame and Android). Can you please tell me what specifically what didn't work for you in comment 42?

Comment 52

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

(In reply to arno from comment #51)
> Ian: I assume you knew about the problem that Eric mentioned in comment 49?
> I just tested the patch on my Flame device (I rebased to latest master) and
> the tests I tried were all working fine (including a simultaneous over-cross
> transfer between Fame and Android). Can you please tell me what specifically
> what didn't work for you in comment 42?

Quick update: bug 1032088 has been fixed by Shawn and I can confirm that file sharing via Bluetooth works as expected on today's build.

Comment 53

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

Hi Arno, I'm able to use NFC sharing file after updated following build version. The patch is working for me too. Looks working fine while a video is sharing by laptop. And Bluetooth won't be turned off after NFC transferred file completely. Great!

===== Build version =====
Gaia      4576db50bee6a3b624773830bf07f6b8dd20ad4a
Gecko     https://hg.mozilla.org/mozilla-central/rev/dfef245594b6
BuildID   20140707160202
Version   33.0a1
ro.build.version.incremental=108
ro.build.date=Tue Jun 10 19:40:40 CST 2014
B1TC20011210

Comment 54

[Ryan VanderMeulen [:RyanVM]]

Master: https://github.com/mozilla-b2g/gaia/commit/fc8a1232c5bb519539c76ddda72bd4fbaf47278a

Comment 55

[Ryan VanderMeulen [:RyanVM]]

Needs rebasing for v2.0 uplift.

Comment 56

[arno]

Dependent bug 948823 has been uplifted to 2.0 so this PR should apply cleanly to the 2.0 branch.

Comment 57

[Ryan VanderMeulen [:RyanVM]]

error: could not apply fc8a123... Merge pull request #19910 from svic/Bug_998175_rebased

Still needs rebasing.

Comment 58

[arno]

Attachment: PR for the v2.0 branch

This is the rebased version for the v2.0 branch. Travis fails but the failures are not related to this patch.

Comment 59

[Ryan VanderMeulen [:RyanVM]]

Thanks :)

v2.0: https://github.com/mozilla-b2g/gaia/commit/e3e3ca7b481178f39f525b7f940799349fbb5c5d

Comment 60

[Alison Shiue]

Gaia      db0358b53488a941ced352d890802342d7ced00e
Gecko     https://hg.mozilla.org/releases/mozilla-aurora/rev/0874ec920408
BuildID   20140715160201
Version   32.0a2

Verify the following scenario:
[Steps]
1. Enable NFC in settings on both phones
2. Device A receiving video from laptop via BT
3. Touch two phones together
4. Swipe screen on Device A to share an image to Device B (laptop still transfer file)

[Result]
After Device A receiving file from laptop, Device A would start transfer file to Device B

Comment 61

[Sue]

Attachment: Device A to device B

This issue has been verified unsuccessfully on Flame v2.0 & v2.1
See attachment: Device A to device B.MP4 and Device B to device A and logcat_Flame2.1.txt
STR 1:
1. Enable NFC in settings on both phones.
2. Device A receiving video from laptop via BT.
3. Touch two phones together.
4. Swipe screen on Device B to share an image to Device A (laptop still transfer file).
**Device A can't received the image from device B.

STR 2:
1. Enable NFC in settings on both phones.
2. Device A receiving video from laptop via BT.
3. Touch two phones together.
4. Swipe screen on Device A to share an image to Device B (laptop still transfer file).
**Device B can't received the image from device A.

Reproducing rate: 5/5
Flame 2.0 versions:
Gaia-Rev        8d1e868864c8a8f1e037685f0656d1da70d08c06
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/c756bd8bf3c3
Build-ID        20141201000201
Version         32.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141201.034308
FW-Date         Mon Dec  1 03:43:18 EST 2014
Bootloader      L1TC00011880

Flame 2.1 versions:
Gaia-Rev        ccb49abe412c978a4045f0c75abff534372716c4
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/18fb67530b22
Build-ID        20141201001201
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141201.034405
FW-Date         Mon Dec  1 03:44:15 EST 2014
Bootloader      L1TC00011880

Comment 62

[Sue]

Attachment: Device B to device A

Hi Hubert,
Could you help with it, thanks.

Comment 63

[Sue]

Attachment: logcat of Flame 2.1

Comment 64

[William Hsu [:whsu]]

NI?whsu to follow up.

Thanks everyone.

Comment 65

[William Hsu [:whsu]]

Hi, Sue,

Could you please use following build to do a cross-comparison?
1) Gaia      db0358b53488a941ced352d890802342d7ced00e
   Gecko     https://hg.mozilla.org/releases/mozilla-aurora/rev/0874ec920408
   BuildID   20140715160201
   Version   32.0a2

2) Latest v2.0 build. (v188 base image)

If both verification results are failed, please file a bug to trace it and note the bug number here.
If it cannot reproduce on "20140715160201" build, I think it is a regression.
Please also file a new bug and tag "regression".
Many thanks!

Comment 66

[Hubert Lu[:hlu] <[e-mail]>]

Hi William,
    I could not find that build "20140715160201" on PVT server, could you help provide the link for Marigold to get the build? Thanks a lot.

Comment 67

[Sue]

Attachment: logcat_deviceA_1901.txt

This issue has been verified fail on latest build of Flame 2.0(v188 base image). When device A receiving a video from laptop via BT, device A can not sent/receive image with device B. I have uploaded the logcat of device A and device B.
I cannot reproduce on "20140715160201" build, as Hubert said in comment 66, can't find the build "20140715160201", wait for build to verify it.

See attachment:logcat_deviceA_1901.txt and logcat_deviceB_1847.txt
Device A found time:19:01
Device B found time:18:47
Rate:5/5

Flame 2.0 build:
Gaia-Rev        31d6c9422cd0a8213df9f96019c9ab7168ec3ab3
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/7c7daab470fb
Build-ID        20150108000200
Version         32.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150108.034549
FW-Date         Thu Jan  8 03:46:00 EST 2015
Bootloader      L1TC00011880

Comment 68

[Sue]

Attachment: logcat_deviceB_1847.txt

Comment 69

[William Hsu [:whsu]]

> I cannot reproduce on "20140715160201" build, as Hubert said in comment 66,
> can't find the build "20140715160201", wait for build to verify it.

Hi, Sue,

Here is the link to download the test build.
- https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/nightly/mozilla-aurora-flame/2014/07/2014-07-14-16-02-01/ 

This a JB base Flame build. I want to do a cross-comparison to see if it is a regression, so I have the request.

You can follow the steps to flash it.
1. Please flash JB base image 
2. If you are using flash tool to flash device, you can select following options to flash it.
   [Device]: Flame -> [Branch]: Mozilla-aurora -> fill the build ID (20140715160201) -> [Build Type]: ENG or USR -> [Gaia/Gecko/Full]: Full


If you have any problem, please feel free to let me know.
Many thanks.

Comment 70

[William Hsu [:whsu]]

Attach Flame v123 base image (office download)
- http://cds.w5v8t3u9.hwcdn.net/v123.zip

Thanks for your help!

Comment 71

[Sue]

Attachment: logcat_deviceA_2051.txt

This issue is verified fail on "20140715160201" build of Flame 2.0
When device A is receiving a video from laptop via BT, device B can't send image to device A via NFC. But when device A is sending a image to device B via NFC, the sending image will be paused. After the video is received on device A, the image will be sent successfully.
I will open a new bug for tracing it.
See attachment:logcat_deviceA_2051.txt and logcat_deviceB_2045.txt and screenshot.png
Gaia-Rev        2c6c413ed729d465c52d6c2d5d458e2eee79e956
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-aurora/rev/d32649a24965
Build-ID        20140714160201
Version         32.0a2
Device-Name     flame
FW-Release      4.3
FW-Incremental  eng.cltbld.20140714.192055
FW-Date         Mon Jul 14 19:21:05 EDT 2014
Bootloader      L1TC00011230

Comment 72

[Sue]

Attachment: logcat_deviceB_2045.txt

Comment 73

[Sue]

Attachment: screenshot.png

Comment 74

[Alison Shiue]

(In reply to Sue from comment #71)
Hi Sue, 

According to comment 23, currently, we could not avoid the race condition for multiple incoming file requests.

> When device A is receiving a video from laptop via BT, device B can't send
> image to device A via NFC. 
This is expected.

> But when device A is sending a image to device B
> via NFC, the sending image will be paused. After the video is received on
> device A, the image will be sent successfully.
This is also an expected result, device A would start to transfer image to device B after received video from laptop.

Comment 75

[William Hsu [:whsu]]

(In reply to Alison Shiue from comment #74)
> (In reply to Sue from comment #71)
> Hi Sue, 
> 
> According to comment 23, currently, we could not avoid the race condition
> for multiple incoming file requests.
> 
> > When device A is receiving a video from laptop via BT, device B can't send
> > image to device A via NFC. 
> This is expected.
> 
> > But when device A is sending a image to device B
> > via NFC, the sending image will be paused. After the video is received on
> > device A, the image will be sent successfully.
> This is also an expected result, device A would start to transfer image to
> device B after received video from laptop.

Thanks Alison.
No more questions.
The result looks good to me.

Comment 76

[Sue]

(In reply to William Hsu [:whsu] from comment #75)
> (In reply to Alison Shiue from comment #74)
> > (In reply to Sue from comment #71)
> > Hi Sue, 
> > 
> > According to comment 23, currently, we could not avoid the race condition
> > for multiple incoming file requests.
> > 
> > > When device A is receiving a video from laptop via BT, device B can't send
> > > image to device A via NFC. 
> > This is expected.
> > 
> > > But when device A is sending a image to device B
> > > via NFC, the sending image will be paused. After the video is received on
> > > device A, the image will be sent successfully.
> > This is also an expected result, device A would start to transfer image to
> > device B after received video from laptop.
> 
> Thanks Alison.
> No more questions.
> The result looks good to me.

Hi William,
So, we don't need to open a new bug? I have also tested with v18D base image and latest build of Flame 2.0/2.1/2.2, when device A is receiving video from laptop via BT, device A can't send/receive image to device B.

Comment 77

[William Hsu [:whsu]]

(In reply to Sue from comment #76)
> (In reply to William Hsu [:whsu] from comment #75)
> > (In reply to Alison Shiue from comment #74)
> > > (In reply to Sue from comment #71)
> > > Hi Sue, 
> > > 
> > > According to comment 23, currently, we could not avoid the race condition
> > > for multiple incoming file requests.
> > > 
> > > > When device A is receiving a video from laptop via BT, device B can't send
> > > > image to device A via NFC. 
> > > This is expected.
> > > 
> > > > But when device A is sending a image to device B
> > > > via NFC, the sending image will be paused. After the video is received on
> > > > device A, the image will be sent successfully.
> > > This is also an expected result, device A would start to transfer image to
> > > device B after received video from laptop.
> > 
> > Thanks Alison.
> > No more questions.
> > The result looks good to me.
> 
> Hi William,
> So, we don't need to open a new bug? I have also tested with v18D base image
> and latest build of Flame 2.0/2.1/2.2, when device A is receiving video from
> laptop via BT, device A can't send/receive image to device B.

We don't need a new bug since Alison has confirmed this result.
Thanks Alison and Sue! :)

Comment 78

[Sue]

(In reply to William Hsu [:whsu] from comment #77)
> We don't need a new bug since Alison has confirmed this result.
> Thanks Alison and Sue! :)

As Alison said in comment 74, device A would start to transfer image to device B after received video from laptop. But I have found device A can't send image to device B when device A is receiving video from laptop via BT, device B will remind "File could not be received". I have opened a new bug, could you help with it?
See Bug 1120849

Comment 79

[William Hsu [:whsu]]

Hi, Alison,

May I have your help?
Could you please review Bug 1120849 to see if it is a bug or expected behavior?
Many thanks! :)

Comment 80

[Alison Shiue]

Yes, if device A should could send file to device B after receiving file from laptop, if not, this is a bug.