Closed
Bug 998175
Opened 11 years ago
Closed 10 years ago
[NFC] Receive Image/video file by NFC from device A, while still receiving file from another device B through BT
Categories
(Firefox OS Graveyard :: NFC, defect)
Tracking
(blocking-b2g:2.0+, b2g-v2.0 fixed, b2g-v2.1 fixed)
People
(Reporter: ashiue, Assigned: arno)
References
Details
(Whiteboard: [2.0-flame-test-run-1], [2.0-flame-test-run-2])
Attachments
(11 files, 1 obsolete file)
(deleted),
text/plain
|
Details | |
(deleted),
text/x-github-pull-request
|
iliu
:
review+
|
Details |
(deleted),
text/x-github-pull-request
|
Details | |
(deleted),
video/mp4
|
Details | |
(deleted),
video/mp4
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
image/png
|
Details |
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
Reporter | ||
Comment 1•11 years ago
|
||
I'm not sure if this issue related to NFC or bluetooth, please correct me if exist any misunderstanding.
Comment 2•11 years ago
|
||
John, I wonder if you could do analysis for this bug first.
Flags: needinfo?(johu)
Comment 3•11 years ago
|
||
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
Flags: needinfo?(johu)
Comment 4•11 years ago
|
||
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.
Flags: needinfo?(ashiue)
Reporter | ||
Comment 5•11 years ago
|
||
No, in this test case, the video file sent by laptop is still transferring when Device B try to share file to Device A.
Flags: needinfo?(ashiue)
Comment 6•11 years ago
|
||
(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.
Flags: needinfo?(btian)
Comment 7•11 years ago
|
||
(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.
Flags: needinfo?(btian)
Comment 8•11 years ago
|
||
I wonder if NFC manger need to reply an error message to notify Device B that handover is impossible in this condition.
Flags: needinfo?(dgarnerlee)
Updated•11 years ago
|
Flags: needinfo?(dgarnerlee)
Comment 9•11 years ago
|
||
Arno, is there an error code or message to handle in handover manager (or bluetooth)?
Flags: needinfo?(arno)
Assignee | ||
Comment 10•11 years ago
|
||
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?
Flags: needinfo?(arno) → needinfo?(iliu)
Comment 12•11 years ago
|
||
(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).
Flags: needinfo?(iliu)
Summary: [NFC] Image/video file receiving by tapping phones together, currently receiving file from another device → [NFC] Receive Image/video file by NFC from device A, while still receiving file from another device B through BT
Assignee | ||
Comment 13•11 years ago
|
||
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.
Flags: needinfo?(iliu)
Comment 14•11 years ago
|
||
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•11 years ago
|
||
(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.
Flags: needinfo?(iliu)
Comment 16•11 years ago
|
||
(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•11 years ago
|
||
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.
Assignee | ||
Comment 18•11 years ago
|
||
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•11 years ago
|
||
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.
Flags: needinfo?(jhuang)
Comment 20•11 years ago
|
||
(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•11 years ago
|
||
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
Flags: needinfo?(jhuang)
Assignee | ||
Comment 23•10 years ago
|
||
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
Flags: needinfo?(iliu)
Comment 25•10 years ago
|
||
(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.
Flags: needinfo?(iliu)
Comment 26•10 years ago
|
||
Comment on attachment 8426686 [details]
Properly handle concurrent file transfers
We have bluetooth_transfer_test and nfc_handover_manager_test so I expect we have tests for changes made.
Attachment #8426686 -
Flags: review?(alive)
Comment 27•10 years ago
|
||
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•10 years ago
|
||
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.
Attachment #8426686 -
Attachment is obsolete: true
Attachment #8433088 -
Flags: review?(alive)
Updated•10 years ago
|
Attachment #8433088 -
Flags: review?(alive) → review?(gweng)
Updated•10 years ago
|
Attachment #8433088 -
Flags: feedback?(iliu)
Comment 30•10 years ago
|
||
Comment on attachment 8433088 [details]
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+.
Attachment #8433088 -
Flags: review?(gweng)
Assignee | ||
Comment 31•10 years ago
|
||
(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?
Assignee | ||
Comment 32•10 years ago
|
||
(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•10 years ago
|
||
OK, I've read the comment and it's fine. Please wait Ian to give his feedback.
Comment 34•10 years ago
|
||
Comment on attachment 8433088 [details]
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.
Attachment #8433088 -
Flags: feedback?(iliu)
Updated•10 years ago
|
status-b2g-v2.0:
--- → affected
Whiteboard: [2.0-flame-test-run-1]
Updated•10 years ago
|
blocking-b2g: 2.0? → 2.0+
Comment 36•10 years ago
|
||
Hi Arno, are you going to be able to update the PR soon? If not, we can find someone else to finish it. Thanks!
Flags: needinfo?(arno)
Updated•10 years ago
|
Whiteboard: [2.0-flame-test-run-1] → [2.0-flame-test-run-1], [2.0-flame-test-run-2]
Updated•10 years ago
|
Blocks: b2g-NFC-2.0
Assignee | ||
Comment 39•10 years ago
|
||
(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.
Flags: needinfo?(arno)
Comment 40•10 years ago
|
||
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.
Target Milestone: --- → 2.0 S5 (4july)
Comment 41•10 years ago
|
||
Comment on attachment 8433088 [details]
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.
Attachment #8433088 -
Flags: review?(iliu)
Comment 42•10 years ago
|
||
Comment on attachment 8433088 [details]
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.
Attachment #8433088 -
Flags: review?(iliu) → review+
Comment 44•10 years ago
|
||
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?
Flags: needinfo?(arno)
Assignee | ||
Comment 45•10 years ago
|
||
(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.
Flags: needinfo?(arno)
Assignee | ||
Comment 47•10 years ago
|
||
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.
Assignee | ||
Comment 48•10 years ago
|
||
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.
Flags: needinfo?(echou)
Comment 49•10 years ago
|
||
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?
Flags: needinfo?(echou) → needinfo?(arno)
Assignee | ||
Comment 50•10 years ago
|
||
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!
Flags: needinfo?(arno)
Assignee | ||
Comment 51•10 years ago
|
||
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?
Flags: needinfo?(iliu)
Comment 52•10 years ago
|
||
(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•10 years ago
|
||
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
Flags: needinfo?(iliu)
Keywords: checkin-needed
Comment 54•10 years ago
|
||
Master: https://github.com/mozilla-b2g/gaia/commit/fc8a1232c5bb519539c76ddda72bd4fbaf47278a
Status: NEW → RESOLVED
Closed: 10 years ago
status-b2g-v2.1:
--- → fixed
Keywords: checkin-needed
Resolution: --- → FIXED
Comment 55•10 years ago
|
||
Needs rebasing for v2.0 uplift.
Flags: needinfo?(arno)
Keywords: branch-patch-needed
Target Milestone: 2.0 S5 (4july) → 2.0 S6 (18july)
Reporter | ||
Updated•10 years ago
|
QA Whiteboard: [NFC]
Reporter | ||
Updated•10 years ago
|
QA Whiteboard: [NFC] → [COM:NFC]
Reporter | ||
Updated•10 years ago
|
QA Whiteboard: [COM:NFC] → [COM=NFC]
Assignee | ||
Comment 56•10 years ago
|
||
Dependent bug 948823 has been uplifted to 2.0 so this PR should apply cleanly to the 2.0 branch.
Flags: needinfo?(arno) → needinfo?(ryanvm)
Comment 57•10 years ago
|
||
error: could not apply fc8a123... Merge pull request #19910 from svic/Bug_998175_rebased Still needs rebasing.
Flags: needinfo?(arno)
Updated•10 years ago
|
Flags: needinfo?(ryanvm)
Assignee | ||
Comment 58•10 years ago
|
||
This is the rebased version for the v2.0 branch. Travis fails but the failures are not related to this patch.
Flags: needinfo?(arno) → needinfo?(ryanvm)
Comment 59•10 years ago
|
||
Thanks :) v2.0: https://github.com/mozilla-b2g/gaia/commit/e3e3ca7b481178f39f525b7f940799349fbb5c5d
Reporter | ||
Comment 60•10 years ago
|
||
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
Status: RESOLVED → VERIFIED
Comment 61•10 years ago
|
||
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 63•10 years ago
|
||
Comment 64•10 years ago
|
||
NI?whsu to follow up. Thanks everyone.
Flags: needinfo?(hlu) → needinfo?(whsu)
Comment 65•10 years ago
|
||
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!
Flags: needinfo?(whsu) → needinfo?(lulu.tian)
Comment 66•10 years ago
|
||
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.
Flags: needinfo?(whsu)
Comment 67•10 years ago
|
||
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•10 years ago
|
||
Comment 69•10 years ago
|
||
> 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.
Flags: needinfo?(whsu)
Comment 70•10 years ago
|
||
Attach Flame v123 base image (office download) - http://cds.w5v8t3u9.hwcdn.net/v123.zip Thanks for your help!
Comment 71•10 years ago
|
||
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
Flags: needinfo?(lulu.tian)
Comment 72•10 years ago
|
||
Comment 73•10 years ago
|
||
Reporter | ||
Comment 74•10 years ago
|
||
(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•10 years ago
|
||
(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•10 years ago
|
||
(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•10 years ago
|
||
(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•10 years ago
|
||
(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•10 years ago
|
||
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! :)
Flags: needinfo?(ashiue)
Reporter | ||
Comment 80•10 years ago
|
||
Yes, if device A should could send file to device B after receiving file from laptop, if not, this is a bug.
Flags: needinfo?(ashiue)
You need to log in
before you can comment on or make changes to this bug.
Description
•