Closed Bug 915584 Opened 11 years ago Closed 11 years ago

[Bluetooth][Contacts] Receiving a contact via bluetooth when the device does not have SD Card flow differs from the expected

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:-)

VERIFIED FIXED
blocking-b2g -

People

(Reporter: isabelrios, Assigned: iliu)

References

Details

(Whiteboard: [u=commsapps-user c=contacts p=0])

Attachments

(1 file)

Master 09/12 build: Gecko-729cc01 Gaia-70800e3 STR Use the device without a SD Card, from another device send a contact via bluetooth to it EXPECTED After being checked with UX (Ayman cc'ed), to be consistent with the WFs ( FFOS_ExportContacts_V1.2_20130805_V3.0.pdf): On Screen 2 of page 08 when the user taps the incoming notification there should be an error screen saying: header: 'no memory card' body: 'Insert a memory card to transfer contacts using BT' CTA: 'OK' Upon selection of the OK CTA the notification of the pending BT transfer will be removed from notifications and replaced with a notification saying '<name_of_VCF_file>.vcf transfer cancelled'.. And the flow should mirror that of step 6 on page 08. ACTUAL All the messages are received at the same time without user interaction: -There is a notification when the file is received: File could not be received, -At the bottom there is a banner: Bluetooth transfer filed. -The screen shown in the background says: Can not receive file. No memory card found (Please insert a memory card) and Confirm. The notification and the banner dissapear after a while, the screen is kept till user presses on Confirm.
Blocks: 915254
I checked this and again, I think this bug belongs to Bluetooth app, as the warning screen should appear even before starting the transfer (and stop it before it happens). Contacts app is only called after we receive the file and the file is a vcard. Pinging Noemi and Joe for an opinion on discussion or a decision, to delegate it to BT team or help to fix it.
Flags: needinfo?(noef)
Flags: needinfo?(jcheng)
ni? Ian
Flags: needinfo?(noef)
Flags: needinfo?(jcheng)
Flags: needinfo?(iliu)
perhaps this bug has been here for the whole time since 1.0 as the phone really needs SD card to function well. Let's get some feedback from Ian first
Not so much related to the issue but just a quick note. I filed another bug this morning to support sending files without an SD card (bug 917645). Currently we do need an SD card for both sending and receiving files. My suggestion was let's keep as is for v1.2.
When sending, currently, there is not any error message or warning to let user know the need of a SD Card. After selecting one contact and tapping on Export Contacts there is only a layaout: 0 out of 1 exported. Depending on when bug 917645 is fixed maybe an error message is needed for this case.
Blocks: 918747
(In reply to Isabel Rios [:isabel_rios] from comment #0) > STR > Use the device without a SD Card, from another device send a contact via > bluetooth to it > > EXPECTED > After being checked with UX (Ayman cc'ed), to be consistent with the WFs ( > FFOS_ExportContacts_V1.2_20130805_V3.0.pdf): > > On Screen 2 of page 08 when the user taps the incoming notification there > should be an error screen saying: > > header: 'no memory card' > body: 'Insert a memory card to transfer contacts using BT' For the body message, could we have a common description for guiding user in this case? If we use the word "contacts", it means that we have to reach the incoming file type before receiving files. Then, we need to give fitting description corresponding each file type(vcard/image/audio/video). It will have many kind of description. > CTA: 'OK' > > Upon selection of the OK CTA the notification of the pending BT transfer > will be removed from notifications and replaced with a notification saying > '<name_of_VCF_file>.vcf transfer cancelled'.. And the flow should mirror > that of step 6 on page 08. > Just want to confirm the flow again. According to above expected flow, the error screen should be pop out after a user tapped the incoming notification and optioned "Accept". If I have any misunderstanding, please feel free to let me know. Thanks.
Flags: needinfo?(iliu)
Flags: needinfo?(cawang)
Flags: needinfo?(aymanmaat)
(In reply to Ian Liu [:ianliu] from comment #6) > (In reply to Isabel Rios [:isabel_rios] from comment #0) > > STR > > Use the device without a SD Card, from another device send a contact via > > bluetooth to it > > > > EXPECTED > > After being checked with UX (Ayman cc'ed), to be consistent with the WFs ( > > FFOS_ExportContacts_V1.2_20130805_V3.0.pdf): > > > > On Screen 2 of page 08 when the user taps the incoming notification there > > should be an error screen saying: > > > > header: 'no memory card' > > body: 'Insert a memory card to transfer contacts using BT' > For the body message, could we have a common description for guiding user in > this case? If we use the word "contacts", it means that we have to reach the > incoming file type before receiving files. Then, we need to give fitting > description corresponding each file type(vcard/image/audio/video). It will > have many kind of description. > > CTA: 'OK' > > > > Upon selection of the OK CTA the notification of the pending BT transfer > > will be removed from notifications and replaced with a notification saying > > '<name_of_VCF_file>.vcf transfer cancelled'.. And the flow should mirror > > that of step 6 on page 08. > > > Just want to confirm the flow again. According to above expected flow, the > error screen should be pop out after a user tapped the incoming notification > and optioned "Accept". If I have any misunderstanding, please feel free to > let me know. Thanks. Maybe we could use the word "file" rather than "contact". And yes, the flow looks good to me. What do you think? Ayman
Flags: needinfo?(cawang)
(In reply to cawang from comment #7) > (In reply to Ian Liu [:ianliu] from comment #6) > > (In reply to Isabel Rios [:isabel_rios] from comment #0) > > > STR > > > Use the device without a SD Card, from another device send a contact via > > > bluetooth to it > > > > > > EXPECTED > > > After being checked with UX (Ayman cc'ed), to be consistent with the WFs ( > > > FFOS_ExportContacts_V1.2_20130805_V3.0.pdf): > > > > > > On Screen 2 of page 08 when the user taps the incoming notification there > > > should be an error screen saying: > > > > > > header: 'no memory card' > > > body: 'Insert a memory card to transfer contacts using BT' > > For the body message, could we have a common description for guiding user in > > this case? If we use the word "contacts", it means that we have to reach the > > incoming file type before receiving files. Then, we need to give fitting > > description corresponding each file type(vcard/image/audio/video). It will > > have many kind of description. > > > CTA: 'OK' > > > > > > Upon selection of the OK CTA the notification of the pending BT transfer > > > will be removed from notifications and replaced with a notification saying > > > '<name_of_VCF_file>.vcf transfer cancelled'.. And the flow should mirror > > > that of step 6 on page 08. > > > > > Just want to confirm the flow again. According to above expected flow, the > > error screen should be pop out after a user tapped the incoming notification > > and optioned "Accept". If I have any misunderstanding, please feel free to > > let me know. Thanks. > > Maybe we could use the word "file" rather than "contact". > And yes, the flow looks good to me. > What do you think? Ayman Hi all Yes the flow Isabel describes is as so, and i also agree with Carrie that we should go for the more generic word 'file' rather than 'contact' as i encapsulates more cases and is therefore easier to maintain.
Flags: needinfo?(aymanmaat)
Assignee: nobody → iliu
OS: Windows 7 → Gonk (Firefox OS)
Hardware: x86_64 → ARM
(In reply to Isabel Rios [:isabel_rios] from comment #0) > header: 'no memory card' > body: 'Insert a memory card to transfer contacts using BT' > CTA: 'OK' Hi all, I find out a question about revised the header from 'Can not receive file' to 'no memory card'. In checking storage status, it will generate many case for following reason. But we only change the header for 'no memory cared' in this case. I think it will have a potential problem on inconsistent prompt message. For the section, it's still needing some discussion to take care each storage case. So, let's modify the description on Bug 922993. === Storage Status === Can not get device storage state No memory card found (Please insert a memory card) #here we're modifying.. Bluetooth can not be used while phone is plugged in. Please unplug the phone to receive file(s). Can not complete transfer: memory card is full. Unknown error
NOTE: For the issue here, I will give a patch for fixing the inconsistent UI flow only.
UX, Please comment if this is a blocker from UX.
Flags: needinfo?(firefoxos-ux-bugzilla)
Reassigning to Mike Tsai and taipei team.
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(mtsai)
I think there is no blocking on UX side for the issue. We separate the string refinement issue via Bug 922993. And Carrie has given a solution there.
Flags: needinfo?(mtsai)
Alive, Could you please help to review my pr? Thanks.
Attachment #819670 - Flags: review?(alive)
Comment on attachment 819670 [details] Pointer to Github pull request 12971.html Thank you for having an unit test! BTW, please rerun travis again.
Attachment #819670 - Flags: review?(alive) → review+
blocking-b2g: koi? → -
Can we land this patch?
Flags: needinfo?(iliu)
I'm stuck in unit test. Because of undefined obj "BluetoothTransfer" is still happened on Travis build report. But I don't meet the problem on my local test environment. I'm trying to fix the problem.
Flags: needinfo?(iliu)
https://travis-ci.org/mozilla-b2g/gaia/jobs/12967663#L1530 Not sure the reason to make the undefined issue.. sad.
Try requireApp in setup.
(In reply to Alive Kuo [:alive] from comment #19) > Try requireApp in setup. The way is still not working. The problem is pretty wired. The test is always working fine locally. Just not work on server side. I have tried many ways to overcome the undefined error on Travis server. I guess the problem here is about adding a new test for a system app's module. And the module is never tested before. Fred also meets the problem for developing new module in system app. The following ways are useless to overcome the problem. * requireApp('system/js/bluetooth_transfer.js'); in suite/setup/suiteSetup scoop * simplify the test case in bluetooth_transfer_test.js * only call "BluetoothTransfer" object in test() scoop * remove all other mock modules(MocksHelper, MockL10n, MockSetMessageHandler) Alive, Could we land the patch without unit test? Then, we add the unit test back in next BT file transfer v1.3 user story. I was blocking on this patch here. Thanks.
Alive, After refined the unit test, it still does not work on Travis server. Does do requireApp('JS_PATH', done) at setup scoop of the outer suite work for you pr? Thanks. https://travis-ci.org/mozilla-b2g/gaia/jobs/13140484
Note: Unit test still not work via overwrite window.BluetoothTransfer. https://travis-ci.org/mozilla-b2g/gaia/jobs/13144121
Don't waste too much time on this, open a followup bug to add tests!
Let's track the unit test via Bug 931725 - [Bluetooth File Transfer] Add unit test for BluetoothTransfer module in system app .
Since the pr is merged, we can close the issue now. Gaia/master: ae19152f5a1d84983dfe6d192c00d10900321a97
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Checked on master 11/19 build: Gecko-59d46a4 Gaia-fa29c2b Now the actual behaviour is: All the messages are received at the same time without user interaction: -There is a notification when the file is received: File could not be received, -The screen shown in the background says: Can not receive file. No memory card found (Please insert a memory card) and Confirm. The only difference is that it appears the word 'file' and that the banner at the bottom does not appear. But still the flow is not as it should as Ayman confirmed on comment 8. To summarize: The SD card needed error screen should pop up after tapping on the incoming notification. Has there been any change and the actual implementation would be the final one? ni Ian Would that be correct? ni Ayman Just to know whether this bug can be definitely closed or not. Thanks
Flags: needinfo?(iliu)
Flags: needinfo?(aymanmaat)
With reference to comment 27 reopening this bug as behaviour is not as expected.
Status: RESOLVED → REOPENED
Flags: needinfo?(aymanmaat)
Resolution: FIXED → ---
Hi Isabel, Is the fixed patch in your build version? I just try to verify the behaviour in latest build version. The flow is following up comment 8. This is my build version. And please make sure again in your build version. Gaia c952e2756c03eceb4de6a3eba15651741a62f9e8 Gecko http://hg.mozilla.org/mozilla-central/rev/df82be9d89a5 BuildID 20131210040206 Version 29.0a1 ro.build.version.incremental=eng.cltbld.20131210.072155
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Flags: needinfo?(iliu) → needinfo?(isabelrios)
Resolution: --- → FIXED
(In reply to Isabel Rios [:isabel_rios] from comment #27) > Checked on master 11/19 build: > Gecko-59d46a4 > Gaia-fa29c2b I see the fixed patch is in your Gaia version(https://github.com/mozilla-b2g/gaia/blob/fa29c2b37b44247a3d1e133924346b22ead41cd3/apps/system/js/bluetooth_transfer.js#L194-L200). We check device storage status after user confirmed to accept the incoming file request. That should be working fine, I think. Is there any other misunderstand in your verification steps? Thanks.
Hi Ian, I checked this issue again and sorry for the confusion, do not why the other time I did not see it right, now it seems to be fine. v1.3 12/16 build: Gecko-6e22321 Gaia-1752e9e Now the flow when receiving a contact is as expected, you receive the request, and it is when user accepts it by tapping on Transfer when the screen about No memory card is shown. Before, all that happened without user interaction So, verifing this bug. Thanks Ian
Status: RESOLVED → VERIFIED
Flags: needinfo?(isabelrios)
Thanks for your verification again.:)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: