1121934 - cannot send some unsupported format files via BT

Status: RESOLVED WORKSFORME

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

Description

[sync-1]

Created an attachment (id=1024265)
 the file which cannot send by MS
 
 		
  DEFECT DESCRIPTION:
 >cannot send some unsupported format file via BT
 
  REPRODUCING PROCEDURES:
 1.send a flv file from MS to remote device via BT;
 
 2.pop-up"file could not be sent"--KO.
 
 PS:之前确认过fire2-3.5通过蓝牙收发文件是没有格式要求的，但是测试发现不能发送.flv/.avs/.pdb文件，也不能发送SP的mtklog文件。
 
  EXPECTED BEHAVIOUR:
 >could send all file normally via BT
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:

Comment 1

[sync-1]

Attachment: log&视频1

Comment 2

[sync-1]

Attachment: log&视频1

Comment 3

[sync-1]

Attachment: log&视频4

Comment 4

[sync-1]

Attachment: log&视频1

Comment 5

[sync-1]

Attachment: log&视频4

Comment 6

[sync-1]

Attachment: log&视频3

Comment 7

[sync-1]

Attachment: log&视频1

Comment 8

[sync-1]

Attachment: log&视频4

Comment 9

[sync-1]

Attachment: log&视频2

Comment 10

[sync-1]

Attachment: log&视频3

Comment 11

[sync-1]

Attachment: log&视频3

Comment 12

[sync-1]

Attachment: log&视频1

Comment 13

[sync-1]

Attachment: the file which cannot send by MS

Comment 14

[sync-1]

Attachment: log&视频4

Comment 15

[sync-1]

Attachment: log&视频2

Comment 16

[sync-1]

Attachment: log&视频5

Comment 17

[Ben Tian (inactive)]

>  PS:之前确认过fire2-3.5通过蓝牙收发文件是没有格式要求的，但是测试发现不能发送.flv/.avs/.
> pdb文件，也不能发送SP的mtklog文件。

Does the receiver receive these files from other devices? Transfer fails if receiver itself doesn't accept these formats of files.

Comment 18

[sync-1]

hi mozilla:
    出现问题时，接收端没有从其他设备接收文件。
 
    现在的现象如下：
    fire2_3.5可以给fire2_3.5通过蓝牙可以正常传送文件，但是通过fire2_3.5给android 4.4（MTK）平台的手机发送，无法正常发送；通过fire2_3.5 给android 4.2(MTK)平台通过蓝牙发送文件正常。
    
    当发送端点击要传送的手机时，接收端没有收到任何提示信息而发送端立即提示发送失败。

Comment 19

[Ben Tian (inactive)]

[Chinese] 我是問其他非 Firefox OS 設備送同樣的檔案給 android 4.4 (MTK) 是否也會失敗? 傳送失敗也可能是接收端拒絕收這些格式的檔案.

[English] I'm asking whether non-FirefoxOS devices also fail to send the same files to the receiver. Transfer fails if receiver itself doesn't accept these formats of files.

(In reply to sync-1 from comment #18)
> hi mozilla:
>     出现问题时，接收端没有从其他设备接收文件。
>  
>     现在的现象如下：
>     fire2_3.5可以给fire2_3.5通过蓝牙可以正常传送文件，但是通过fire2_3.5给android
> 4.4（MTK）平台的手机发送，无法正常发送；通过fire2_3.5 给android 4.2(MTK)平台通过蓝牙发送文件正常。
>     
>     当发送端点击要传送的手机时，接收端没有收到任何提示信息而发送端立即提示发送失败。

Comment 20

[sync-1]

hi mozilla:
    non-FirefoxOS can successfully send the same files to the receiver which is android 4.4(MTK)。

Comment 21

[Shally Li（leave from Mozilla）]

Hi Reporter,

  Could you help to confirm whether the steps are correct?

Thank you very much!


I can repro this bug on Woodduck v2.0 and Flame 2.0&2.1&2.2 by these steps.
See attachment: v2.2_share_1405.MP4 and logcat_v2.2_1405.txt.
Reproduce rate: 0/5.

STR:
1.Download "File Manager" app from Marketplace.
2.Copy the "avs" "pdb" "flv" file into internal storage.
3.Open the "File Manager" app and share the file to Android 4.1.1(HTC)device via bluetooth.
**"File could be not sent" will pop up,and it has no any prompt on Android device.
4.Share the file to other flame device via bluetooth.
**File can be recieved but can't be opened on other flame device.


Woodduck 2.0 build:
Gaia-Rev        22e3b7855281aa7b6190e01b4bd50c79880a1e6a
Gecko-Rev       20943fe7b54c63a375952fbd8dd396a22ee893e7
Build-ID        20150116050313
Version         32.0
Device-Name     jrdhz72_w_ff
FW-Release      4.4.2
FW-Incremental  1421355897
FW-Date         Fri Jan 16 05:05:17 CST 2015

Flame 2.0 build:
Gaia-Rev        736933b25ded904f0cb935a0d48f1f3cf91d33ad
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/8ff0d933175c
Build-ID        20150115000203
Version         32.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150115.031720
FW-Date         Thu Jan 15 03:17:28 EST 2015
Bootloader      L1TC000118D0

Flame 2.1 build:
Gaia-Rev        8d4846d7bec777046dc5e3d2b8005adb1370f1f7
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/8eb9bc3a945a
Build-ID        20150115001207
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150115.035035
FW-Date         Thu Jan 15 03:50:46 EST 2015
Bootloader      L1TC000118D0

Flame 2.2 build:
Gaia-Rev        7c5b27cad370db377b18a742d3f3fdb0070e899f
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/ce27f2692382
Build-ID        20150115002505
Version         37.0a2
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150115.035734
FW-Date         Thu Jan 15 03:57:45 EST 2015
Bootloader      L1TC000118D0

Comment 22

[Shally Li（leave from Mozilla）]

File Manager version :1.0-beta2.20150115.

Comment 23

[sync-1]

hi mozilla:
    your steps are correct

Comment 24

[Josh Cheng [:josh]]

Hi Shally,
I do not understand, you said you can reproduce. However the rate is 0/5? Can you repo or cannot?

Comment 25

[Shally Li（leave from Mozilla）]

(In reply to Josh Cheng [:josh] from comment #24)
> Hi Shally,
> I do not understand, you said you can reproduce. However the rate is 0/5?
> Can you repo or cannot?

Sorry to update:
Reproduce rate is 5/5.

Comment 26

[Josh Cheng [:josh]]

Hi Ben,
It seems to be generic issue. Could you help to check again? Thanks!

Comment 27

[Ben Tian (inactive)]

Will will help on this bug. Assign owner to him.

Comment 28

[sync-1]

hi mozilla:
    any update so far?

Comment 29

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

Things about MIME type

IrOBEX v1.2
2.2.3 Type
"If no Type is specified, the assumed type is binary, and it is up to the receiving software to deal with it as
best it can. This may involve simply storing it without modification of any kind under the stated name,
and/or trying to recognize it by the extension on the name. For instance, a Microsoft Word file could be
sent with no type, and the receiving software, seeing the .doc suffix could choose to interpret it as a
Word file.
Though the Type header is very useful for transfer of non-file object types, it is optional - the receiving
application may know what to do with the object based on context, name, or other factors."

Comment 30

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

Mime types:
http://www.iana.org/assignments/media-types/media-types.xhtml

Comment 31

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

Will, please update your experiment results.

Comment 32

[Will Wang [:WillWang]]

Hi reporter,

My investigation is as following: 

1. Android will only accept to receive some MIME types(whitelist), or, it will reject the incoming bluetooth transfer request.
2. And, in normal case, Android will also reject file without MIME type specified, however, it is "up to the receiving software" as Shawn mentioned, that is, Android behavior may vary.
3. We found that file manager on FFOS sent 3 file types (avs/flv/pdb) without MIME type, so two behavior were showed in your side: 
    a. Android phone A(4.4) reject it
    b. Another Android phone B(4.2) accept it
  I suppose this is not about the Android version, it is about the behavior implementation of phones.
  That is, can you identify whether the MIME type whitelist(or behavior about empty MIME type) is modified or not in the Android phone B?
4. the reason of file manager on FFOS sending files without MIME type is under investigation
5. FYI, avs and flv may be belong to MIME type as [video/avs-video] and [video/x-flv] respectively, and *.pdb is currently not found for any corresponding MIME type 
6. Please note: phone(Android or FFOS) have ability to change the MIME type of file to any type if it want.

Thanks!

Comment 33

[sync-1]

hi mozilla:
    As your investigation,Can you change the MIME type of file and make them can be sent to android 4.4 phone with BT?

Comment 34

[sync-1]

hi mozilla:
 
 下面是android的sendfile代码:
 
 private int sendFile(BluetoothOppSendFileInfo fileInfo)
 
 来看一下参数:
 --------------->  public class BluetoothOppSendFileInfo {
 .................
 ................
 public final String mMimetype;
 ...................
 }
 
 android目前sendfile时是有这个参数的,而FFOS中sendfile():
 BluetoothOppManager::SendFile(const nsAString& aDeviceAddress,
                               nsIDOMBlob* aBlob)
 
 nsIDOMBlob* aBlob应该是没有mMimetype这个参数.
 
 请帮忙修改添加mMimetype这个参数，可以正常的跟android4.4手机通过蓝牙传送文件

Comment 35

[Will Wang [:WillWang]]

Hi reporter

FxOS phone can transfer regular file types with correct MIME type to Android phone,
it is not about whether the function parameter exists or not  

Since these 3 types is not in the latest official IANA document:
http://www.iana.org/assignments/media-types/media-types.xhtml

so it need to be discussed that how to properly enhance this kind of cases.

Comment 36

[Will Wang [:WillWang]]

Please leave your comment if needed, thanks!

Comment 37

[sync-1]

hi mozilla:
    This bug is caused by android mobile refused to receive files?
 
    Maybe you can add a public type to deal with the bug which the file type is absence

Comment 38

[Will Wang [:WillWang]]

Hi reporter

Android will reject file with empty/not-in-whitelist MIME type, and this is related to security reason
We better not "fake" the type to break through the intended protection 

However, if MIME type provided by upper application is wrong, intentionally or not,
it need to be discussed that how to properly detect/handle 

Please leave your comment if any,
thanks!

Comment 39

[sync-1]

Created an attachment (id=1152450)
 MimeType in android

Comment 40

[sync-1]

Created an attachment (id=1152450)
 MimeType in android

Comment 41

[sync-1]

Attachment: MimeType in android

Created an attachment (id=1152450)
 MimeType in android

Comment 42

[sync-1]

hi mozilla:
    I have update the file which is mimetype in android.fire2_3.5 can follow the mimetype with android.   
    However, if MIME type provided by upper application is not,we can modified it with the new attachment before send it.

Comment 43

[Will Wang [:WillWang]]

Hi reporter

(In reply to sync-1 from comment #42)
> hi mozilla:
>     I have update the file which is mimetype in android.fire2_3.5 can follow
> the mimetype with android.   
May you help to address the reason you provide the android MIME type list and request FxOS to follow

>     However, if MIME type provided by upper application is not,we can
> modified it with the new attachment before send it.
Do you mean that you consider the Bluetooth function should detect and correct the wrong MIME type given by app?

Comment 44

[sync-1]

hi mozilla:
    Can you tell me what you design to solve this problem ?

Comment 45

[Will Wang [:WillWang]]

Hi reporter

(In reply to sync-1 from comment #44)
> hi mozilla:
>     Can you tell me what you design to solve this problem ?

Since there is no standard behavior, it is open to be discussed,
First, my consideration in brief:
1. If upper app leave MIME type empty, two possible reasons:
    a. app didn't behave correctly
    b. no such MIME type for this kind of file
  OPP may query the type from gecko again to help solve (a) for app, and cannot handle (b).
2. If upper app provides any MIME type, OPP should use that and send the file.

How is yours?

And as comment 43, may you help to address the reason you provide the android MIME type list and request FxOS to follow?

Comment 46

[Will Wang [:WillWang]]

Hi Dominic

from my comment 45,
If any, may you have any comment/correction for this?
thanks for your help!

Comment 47

[Dominic Kuo [:dkuo]]

The bluetooth app use this bluetooth api to send file:
https://developer.mozilla.org/en-US/docs/Web/API/BluetoothAdapter.sendFile

The two necessary parameters are the |deviceAddress| and |file|, so actually the bluetooth app does not care about the mimetype of the file/blob, even the mimetype is empty or unsupported while sending the files.

I don't know the gecko implementation but I guess currently it probably use the file/blob's |type| property as the mimetype, which means if |blob.type| is empty, the utility function(if there is one) for matching mimetype does not have the mapping of these formats, and maybe we can find the mapping table then add the new mimetypes that the reporter is requesting for?

Comment 48

[Will Wang [:WillWang]]

Hi reporter

please reply comment 45,

recap for you:
1. agree my consideration or have other comment
2. address the reason 

thanks!

Comment 49

[Will Wang [:WillWang]]

(In reply to Dominic Kuo [:dkuo] from comment #47)
> The bluetooth app use this bluetooth api to send file:
> https://developer.mozilla.org/en-US/docs/Web/API/BluetoothAdapter.sendFile
> 
> The two necessary parameters are the |deviceAddress| and |file|, so actually
> the bluetooth app does not care about the mimetype of the file/blob, even
> the mimetype is empty or unsupported while sending the files.
> 
> I don't know the gecko implementation but I guess currently it probably use
> the file/blob's |type| property as the mimetype, which means if |blob.type|
> is empty, the utility function(if there is one) for matching mimetype does
> not have the mapping of these formats, and maybe we can find the mapping
> table then add the new mimetypes that the reporter is requesting for?

Hi Dominic

Thanks for your comment!

Comment 50

[sync-1]

hi mozilla:
    I agree your consideration.
 
    In gecko,mBlob->GetType(mimeType),the mimeType always is null.(the function is in gecko/dom/bluetooth/bluedroid/BluetoothOppManager.cpp)
 
    if you send a file with out name suffix,the bug must repo.

Comment 51

[Josh Cheng [:josh]]

(In reply to sync-1 from comment #50)
> hi mozilla:
>     I agree your consideration.
>  
>     In gecko,mBlob->GetType(mimeType),the mimeType always is null.(the
> function is in gecko/dom/bluetooth/bluedroid/BluetoothOppManager.cpp)
>  
>     if you send a file with out name suffix,the bug must repo.

Hi Reporter,
The current behavior is by design as MIME type is null for some unsupported file. However if the app handles them correctly. They can still be processed as this is not an issue anymore.

Thanks!