Gaia 2f89c43e798ccba631025bedc47a1fb24e830cf2 Gecko https://hg.mozilla.org/mozilla-central/rev/4b6d63b05a0a BuildID 20140512160204 Version 32.0a1 Device Nexus 4 STR: 1. launch "settings" app for 2 phones 2. turn on "NFC" for 2 phones 3. turn off "bluetooth" for 2 phones 4. device A share image via NFC to device B (device B receive successfully) 5. turn on "bluetooth" for 2 phones 6. device A share image via BT to device B (device B receive successfully) Expected result: 1. pop-up transfer confirmed dialog on receiver 2. after transfer, both phones BT should still on Actual result: 1. directly transfer without confirmed dialog 2. after transfer, receiver BT been turn off

Receiver doesn't clean incomingFileTransferInProgress flag in nfc_handover_manager.js so bluetooth transfer app still regards itself in NFC transferring. I tried attached quick fix and the bug is gone. Arno, can you help check this bug?

Set component to NFC.

(In reply to Ben Tian [:btian] from comment #1) > Created attachment 8421619 [details] [diff] [review] > nfc-flag.patch > > Receiver doesn't clean incomingFileTransferInProgress flag in > nfc_handover_manager.js so bluetooth transfer app still regards itself in > NFC transferring. I tried attached quick fix and the bug is gone. > > Arno, can you help check this bug? Ben: nice catch. Yes, that patch ought to do it. I'll prepare a PR.

Evelyn: please don't bother to look at this PR. It is subsumed by the patch for bug 998175. Sorry about that.

Comment on attachment 8424960 [details] Clear incoming file request I'm a bit lost in these series patches (includes those turning BT on/off after file transferred), maybe it's because I don't have a device to play with. I feel the patch is safe but I hope we can have someone to go through the whole scenario and sort out the code to fulfill every case instead of having line by line patches.

Arno is working on this bug.

triage: break expected user flow

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.

Hi Arno, are you still working on this bug? Or kamil would take this bug?

(In reply to Ken Chang[:ken] from comment #10) > Hi Arno, are you still working on this bug? Or kamil would take this bug? This bug should be closed and marked as a duplicate of bug 998175.

Thanks, Arno. According to comment 11, close this bug.

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

verify with Flame KK v180 + v2.0 gaia/gecko, it's fine Gaia 7edd3b0b9f65c3dde235c732d270e43e055a1254 Gecko https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/f3639e825b3b BuildID 20140915135336 Version 32.0

This issue has been verified successfully on Flame v2.0 & v2.1 See attachment: verify_video.MP4 Reproducing rate: 0/5 Flame 2.0 versions: Gaia-Rev 8d1e868864c8a8f1e037685f0656d1da70d08c06 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/c756bd8bf3c3 Build-ID 20141202000201 Version 32.0 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20141202.034707 FW-Date Tue Dec 2 03:47: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 20141202001201 Version 34.0 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20141202.034824 FW-Date Tue Dec 2 03:48:34 EST 2014 Bootloader L1TC00011880