1140247 - [Flame][Contacts] It always shows the word "Connecting.." under paired device when user shares contact info via bluetooth.

Status: VERIFIED FIXED

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

Description

[Shally Li（leave from Mozilla）]

[1.Description]:
[Flame][v2.2&3.0][Contacts] It always shows "Connecting.." under paired device and the other paired  deivce will not receive any request message when user shares a contact via bluetooth from contact detail page.
Found time:14:52
Attch:bluettoth_share_contact.MP4 and logcat_1452.txt.

[2.Testing Steps]: 
Prerequisite: have one paired deivce at least.

1. Launch Contacts app. 
2. Select an existing contact to enter detail page. 
3. Tap "Share Contact" button and select Bluetooth,then choose the paired device. 

[3.Expected Result]: 
3.The paired deivce receives request message and test device will back to contact detail page.

[4.Actual Result]: 
3.The prompt "The transfer has started" pops up and it always shows the word "Connecting.." under paired device, and the other paired deivce doesn‘t receive any request message.

[5.Reproduction build]: 
Flame 2.2 build:
Build ID               20150305002528
Gaia Revision          89af288bad6751248ff84504fa898206fee127fe
Gaia Date              2015-03-04 18:00:05
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/6d8d294aa8f3
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150305.094337
Firmware Date          Thu Mar  5 09:43:49 EST 2015
Bootloader             L1TC000118D0

Flame 3.0 build:
Build ID               20150305072141
Gaia Revision          0017f2bbc63781a5409644b664d80ebaa1543653
Gaia Date              2015-03-05 00:46:59
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/993eb76a8bd6
Gecko Version          39.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150305.160341
Firmware Date          Thu Mar  5 16:03:51 EST 2015
Bootloader             L1TC000118D0

[6.Reproduction Frequency]: 
Always Recurrence,5/5

[7.TCID]: 
9239

[8.Note]:
When you don't pair any device,in step 3,you need turn on Bluetooth and tap on a device to pair,after paired,this bug also exists.

Comment 1

[Shally Li（leave from Mozilla）]

Attachment: logcat_1452.txt

Comment 2

[Shally Li（leave from Mozilla）]

Attachment: bluettoth_share_contact.MP4

Comment 3

[Eric Chang [:ericcc] [:echang]]

Hi Shally,
Could you try this again with turning bluetooth daemon on, thanks.

[3] The way to enable bluetooth daemon: 
adb shell setprop ro.moz.bluetooth.backend bluetoothd
adb shell stop b2g
adb shell start b2g

Comment 4

[Shally Li（leave from Mozilla）]

(In reply to Eric Chang [:ericcc] [:echang] from comment #3)
> Hi Shally,
> Could you try this again with turning bluetooth daemon on, thanks.
> 
> [3] The way to enable bluetooth daemon: 
> adb shell setprop ro.moz.bluetooth.backend bluetoothd
> adb shell stop b2g
> adb shell start b2g

Hi Eric,
    
    After I run above commands,this bug still exists.Please see "new_log1750.txt".

Comment 5

[Shally Li（leave from Mozilla）]

Attachment: new_logcat1750.txt

Comment 6

[Johan Lorenzo [:jlorenzo]]

QA wanted to check 2.2 with the old way to export a single contact (Settings -> Export contact -> Bluetooth). If it does repro there, please check 2.1.

Comment 7

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

I was able to reproduce this issue on 3.0 and 2.2 Flame as written.  However when using Bluetooth from the export menu, the issue did not occur.

Environmental Variables:
Device: Flame 3.0
BuildID: 20150306040833
Gaia: 70fb49fb147d237ce3de4654daef2976e23fbfba
Gecko: 7d85ac833cff
Version: 39.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0

Environmental Variables:
Device: Flame 2.2
BuildID: 20150306094626
Gaia: f6942d4edcbb36ed84b78cc16a8366ae6e033981
Gecko: a1bdc41eefd8
Version: 37.0 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

This issue cannot be reproduced on Flame 2.1 because sharing through the contact details is not an option.

Environmental Variables:
Device: Flame 2.1
BuildID: 20150305113112
Gaia: ea97a87048a4c1e2a479bbea1d75e0a182b2c4c9
Gecko: 871071010b5b\
Version: 34.0 (2.1) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Comment 8

[Alissa（leave from Mozilla）]

This issue has been Failed verified on Nexus5-2.2 and Nexus5-3.0
Reproducing rate: 5/5
N5 2.2
20150308002503
Gaia Revision          166491b92278dc9e648f8d49ab02d9ca00d74421
Gaia Date              2015-03-06 18:26:27
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/a48af0b5a6e4
Gecko Version          37.0
Device Name            hammerhead
Firmware(Release)      5.0
Firmware(Incremental)  eng.cltbld.20150308.052750
Firmware Date          Sun Mar  8 05:28:06 EDT 2015
Bootloader             HHZ12d

N5 3.0:
Build ID               20150308160204
Gaia Revision          fea83511df9ccba64259346bc02ebf2c417a12c2
Gaia Date              2015-03-08 06:36:28
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/eab4a81e4457
Gecko Version          39.0a1
Device Name            hammerhead
Firmware(Release)      5.0
Firmware(Incremental)  eng.cltbld.20150308.192431
Firmware Date          Sun Mar  8 19:24:47 EDT 2015
Bootloader             HHZ12d

Comment 9

[Johan Lorenzo [:jlorenzo]]

[Blocking Requested - why for this release]: Broken new functionality

Comment 10

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

triage: broken function

Comment 11

[Francisco Jordano [:arcturus] [:francisco]]

After finally taking a deep look to this, the problem is not happening in the contacts app, but in the bluethooth settings.

Once we connect with the device, we need to return from the activity, or display a different message in settings for bluethooth.

Moving to the correct component.

Comment 12

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

03-11 15:27:46.061 W/Bluetooth Manager( 5057): [JavaScript Error: "TypeError: activity.source.data.filepaths is undefined" {file: "app://bluetooth.gaiamobile.org/gaia_build_defer_transfer.js" line: 356}]

Comment 13

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

I tested share file from Gallery, it works. But sharing contacts to the remote actually fail :(
Ian, Comment 12, it looks like js error.

Comment 14

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Hi Ian,
Do you have any idea?

Comment 15

[KTucker [:KTucker][Inactive 3/4/2016]]

Unable to provide a regression window here since this not a regression. The earliest Mozilla central build that has the implementation of the share activity in contact details reproduces this "connecting..." issue.

Environmental Variables:
Device: Flame 2.2
BuildID: 20150112122447
Gaia: 7c5b27cad370db377b18a742d3f3fdb0070e899f
Gecko: 34c1ede59beb
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 37.0a1 (2.2) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Comment 16

[Shally Li（leave from Mozilla）]

Hi All,

    When sharing ringtones in Settings/Sound/Manage Tones via Bluetooth,it also exists this bug on Flame v2.2&3.0 (Rate:5/5).
    Please see log "logcat_v2.2_1243.txt" and video "share_ringtones_v2.2.mp4".

Thanks.

Comment 17

[Shally Li（leave from Mozilla）]

Attachment: logcat_v2.2_1243.txt

Comment 18

[Shally Li（leave from Mozilla）]

Attachment: share_ringtones_v2.2.mp4

Comment 19

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

(In reply to Shally from comment #17)
> Created attachment 8576437 [details]
> logcat_v2.2_1243.txt

03-12 12:43:07.712 W/Bluetooth Manager( 1795): [JavaScript Error: "TypeError: activity.source.data.filepaths is undefined" {file: "app://bluetooth.gaiamobile.org/gaia_build_defer_transfer.js" line: 356}]

The same error.

Comment 20

[Shally Li（leave from Mozilla）]

Hi Eric,

   When bluetooth daemon is running("[init.svc.bluetoothd]: [running]","[ro.moz.bluetooth.backend]: [bluetoothd]"),I also repro this bug on Flame v2.2&3.0, thanks.


Flame 2.2 build (affected):
Build ID               20150312002501
Gaia Revision          572d60e0a440ee4af50bc6b6adad8876eadbdb4d
Gaia Date              2015-03-12 01:29:41
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/244e6ba3c20e
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150312.040315
Firmware Date          Thu Mar 12 04:03:26 EDT 2015
Bootloader             L1TC000118D0

Flame 3.0 build (affected):
Build ID               20150312160232
Gaia Revision          eabe35cf054d47087b37c1ca7db8143717fbd7f3
Gaia Date              2015-03-12 18:01:49
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/42afc7ef5ccb
Gecko Version          39.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150312.194521
Firmware Date          Thu Mar 12 19:45:32 EDT 2015
Bootloader             L1TC000118D0

Comment 21

[Eric Chang [:ericcc] [:echang]]

Hi Shally, thank you, let's wait for the patch.

Comment 22

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

The no filepath problem here is a long issue ago. Some of the apps want to share a file without file name in blob, it will hit the problem again. Such as Shally’s comment 16, the ringtone is not able to share via bluetooth(bug 1018804). These apps don’t provide filepath for sharing via Bluetooth.

ringtone: https://github.com/mozilla-b2g/gaia/blob/master/apps/ringtones/js/actions_menu.js#L82-L95
contacts: https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/contacts/js/views/details.js#L658-L666

But the root cause is no file name in blob because app wants to share a blob which is just located in memory, not a file located in storage. So, app cannot pass the filepath while requesting share activity. In part of Bluetooth OOP protocol, the file name is a *required field in transferring process. So, we have to fill in the file name(event if ‘Unknown_Name’) before ask platform to send file. Otherwise, platform will help to fill in with filename 'Unknown'.

Since app can provide file name for share activity(because each activity service will need to show the file name), Bluetooth can provide wrapping the no-name blob with input file name. Once the file has been sent completely, we delete the temp file immediately. I know the approach is not good enough now. Otherwise, Bluetooth app have to filter out the share activity if there is no ‘filepath’ in the request.

After the proposal done, the code flow would be as following.
* Blob with name, send it directly.
* Blob without name, has filepath, get the file via filepath, then send the file.
* Blob without name and filepath, wrap the blob with filename, then send the temp file. After send file completely, delete the file from temp folder.

Comment 23

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

Attachment: pull request 28863

David and Dominic,

Per comment 22, we might not to ask each app to pass filepath while requesting share activity. If they want to share a blob with filename, they might to do what I have done in the patch. If you agree with my proposal, please to review my patch. The idea is coming form ensure_file_backed_blob module in Gallery app. Thanks.

Comment 24

[David Flanagan [:djf]]

Comment on attachment 8577160 [details] [review]
pull request 28863

I don't like this approach with the temporary files.

If I understand correctly, the bluetooth prototcol requires a filename for the transfer. But I don't understand why the defaultAdaptor.sendFile() function can't be modified to make up a filename if it is passed a blob that does not have one.  Or why it can't be modified to take a filename as an optional third argument.  It seems to me that we should fix our bluetooth API instead of doing gaia hacks like this.

Also, when you patch has a device storage failure, it falls back on calling sendFile() with no name. But if that works, why can't we just do it and forget about the temporary file business?

I see that this is a 2.2 blocker, and understand that there may not be time for gecko fixes, so if you really have to land a gaia workaround, please:

1) file a bug for a proper gecko-based fix

2) look at my various comments on github and address at least some of them.

Comment 25

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

(In reply to David Flanagan [:djf] from comment #24)
> Comment on attachment 8577160 [details] [review]
> pull request 28863
> 
> I don't like this approach with the temporary files.
> 
> If I understand correctly, the bluetooth prototcol requires a filename for
> the transfer. But I don't understand why the defaultAdaptor.sendFile()
> function can't be modified to make up a filename if it is passed a blob that
> does not have one.  Or why it can't be modified to take a filename as an
> optional third argument.  It seems to me that we should fix our bluetooth
> API instead of doing gaia hacks like this.
Need info Ben for discussion here. Ben, do you think it's possible to have an optional argument 'filename' for sendFile() API. Thanks.
> 
> Also, when you patch has a device storage failure, it falls back on calling
> sendFile() with no name. But if that works, why can't we just do it and
> forget about the temporary file business?
Just sending the file without name is my original solution. But, the receiver device will get a 'Unknown' file name. That might be hard to use the received file for receiver. I also agree with the solution. And we can use the solution at least. But to make the file with name for transferring file(s), it's meaningful to let receiver know what he/she has received the file(s).
> 
> I see that this is a 2.2 blocker, and understand that there may not be time
> for gecko fixes, so if you really have to land a gaia workaround, please:
> 
> 1) file a bug for a proper gecko-based fix
> 
> 2) look at my various comments on github and address at least some of them.

David, if you think that the patch is really hacking, we can fix the blocking problem for stuck in Bluetooth app first. Then, we use reasonable time to fix no name file sending issue in other bug. Need info for decision instead of review request.

Comment 26

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

Comment on attachment 8577160 [details] [review]
pull request 28863

Per above comment, clean up review request.

Comment 27

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

Attachment: pull request 28884

The patch is fixing for post result while app sends file without name/filepath. David, if you agree with above comment, please help to review the patch. Thanks.

Comment 28

[David Flanagan [:djf]]

Comment on attachment 8577907 [details] [review]
pull request 28884

I like this patch because it is nice and simple and solves the immediate blocking problem. The question of what to do with blobs that don't have names is almost a ux issue, and I hope it can be fixed separately in gecko and that it is something we don't need to block on.

Before landing this patch, I recommend moving the debug() call out of the sendFile() method and just calling debug() before or after each sendFile() call.

Comment 29

[Ben Tian (inactive)]

(In reply to Ian Liu [:ianliu] from comment #25)
> Need info Ben for discussion here. Ben, do you think it's possible to have
> an optional argument 'filename' for sendFile() API. Thanks.

It's possible but gecko requires more time to modify API and design as David mentioned in comment 24. Agree to fix this 2.2 blocker first and we can further work on gecko-based fix.

Comment 30

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

Since the patch is landed, we can close the issue now.

Gaia/master: https://github.com/mozilla-b2g/gaia/commit/ecb1fdb1368d8ba27edabb8bb940fadcff4cb9d3

Comment 31

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

Comment on attachment 8577907 [details] [review]
pull request 28884

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): In v2.2, since Contacts app shares blob without filename/filepath, Bluetooth app is stuck in get the file from device storage with the input filepath.
[User impact] if declined: Bluetooth app won't post result to Contacts app.
[Testing completed]: Manual test, and no tests are failed on try-serve.
[Risk to taking this patch] (and alternatives if risky): Low risk.
[String changes made]: Non.

Comment 32

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

This issue is not fixed in the latest Night Flame 3.0 build.

Actual Results: The contact is shared and can be received by the other device.  However the received file is considered unknown and cannot be opened.

This might require a different bug instead, but for now I'm marking this as a failed verification.

Environmental Variables:
Device: Flame 3.0
BuildID: 20150318055750
Gaia: b8051d370ddf4e5bd8e7d8a19fb9eeb5fd6ffb39
Gecko: 41a61514461e
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 39.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0

Comment 33

[Noemí Freire (:noemi)]

(In reply to Jayme Mercado [:JMercado] from comment #32)
> This issue is not fixed in the latest Night Flame 3.0 build.
> 
> Actual Results: The contact is shared and can be received by the other
> device.  However the received file is considered unknown and cannot be
> opened.
> 
> This might require a different bug instead, but for now I'm marking this as
> a failed verification.


Hi,

Bug 1144610 gather this. Thanks!

Comment 34

[Ryan VanderMeulen [:RyanVM]]

v2.2: https://github.com/mozilla-b2g/gaia/commit/3684a824237515169e23540caae162f0f0ca4e67

Comment 35

[Elie]

This issue verified successfully on flame 2.2
Build ID               20150322002503
Gaia Revision          44c62060581fde8de1e12e94cf55e9673b401a47
Gaia Date              2015-03-20 19:05:17
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/e6140a32902a
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150322.043216
Firmware Date          Sun Mar 22 04:32:27 EDT 2015
Bootloader             L1TC000118D0
Reproduce rate         0/10

Comment 36

[Elie]

(In reply to Elie from comment #35)
> This issue verified successfully on flame 2.2
> Build ID               20150322002503
> Gaia Revision          44c62060581fde8de1e12e94cf55e9673b401a47
> Gaia Date              2015-03-20 19:05:17
> Gecko Revision        
> https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/e6140a32902a
> Gecko Version          37.0
> Device Name            flame
> Firmware(Release)      4.4.2
> Firmware(Incremental)  eng.cltbld.20150322.043216
> Firmware Date          Sun Mar 22 04:32:27 EDT 2015
> Bootloader             L1TC000118D0
> Reproduce rate         0/10
This issue is not happened,but there is a new problem here,The contact is shared and can be received by the other device.  However the received file is considered unknown and cannot be opened.

Comment 37

[Shally Li（leave from Mozilla）]

This bug has been successfully verified on latest Nightly Flame v2.2&3.0 in " https://bugzilla.mozilla.org/show_bug.cgi?id=1144610#c17 ".

Actual results:User can share contact info via bluetooth from contact detail page and no "Connecting.." error message.The paired deivces can receive/open ".vcf" file normally.