cannot send some unsupported format files via BT

RESOLVED WORKSFORME

Status

Firefox OS
Bluetooth
P2
normal
RESOLVED WORKSFORME
4 years ago
3 years ago

People

(Reporter: sync-1, Assigned: WillWang)

Tracking

unspecified
Dependency tree / graph

Firefox Tracking Flags

(tracking-b2g:backlog, b2g-v2.0 affected, b2g-v2.0M affected, b2g-v2.1 affected, b2g-v2.2 affected)

Details

Attachments

(17 attachments)

9.54 MB, application/x-rar-compressed
Details
9.54 MB, application/x-rar-compressed
Details
9.54 MB, application/x-rar-compressed
Details
9.54 MB, application/x-rar-compressed
Details
9.54 MB, application/x-rar-compressed
Details
9.54 MB, application/x-rar-compressed
Details
9.54 MB, application/x-rar-compressed
Details
9.54 MB, application/x-rar-compressed
Details
9.54 MB, application/x-rar-compressed
Details
9.54 MB, application/x-rar-compressed
Details
9.54 MB, application/x-rar-compressed
Details
9.54 MB, application/x-rar-compressed
Details
1.02 MB, application/x-rar-compressed
Details
9.54 MB, application/x-rar-compressed
Details
9.54 MB, application/x-rar-compressed
Details
1.70 MB, application/x-rar-compressed
Details
20.89 KB, text/plain
Details
(Reporter)

Description

4 years ago
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:
(Reporter)

Comment 1

4 years ago
Created attachment 8549558 [details]
log&视频1
(Reporter)

Comment 2

4 years ago
Created attachment 8549563 [details]
log&视频1
(Reporter)

Comment 3

4 years ago
Created attachment 8549564 [details]
log&视频4
(Reporter)

Comment 4

4 years ago
Created attachment 8549568 [details]
log&视频1
(Reporter)

Comment 5

4 years ago
Created attachment 8549570 [details]
log&视频4
(Reporter)

Comment 6

4 years ago
Created attachment 8549571 [details]
log&视频3
(Reporter)

Comment 7

4 years ago
Created attachment 8549573 [details]
log&视频1
(Reporter)

Comment 8

4 years ago
Created attachment 8549574 [details]
log&视频4
(Reporter)

Comment 9

4 years ago
Created attachment 8549575 [details]
log&视频2
(Reporter)

Comment 10

4 years ago
Created attachment 8549576 [details]
log&视频3
(Reporter)

Comment 11

4 years ago
Created attachment 8549578 [details]
log&视频3
(Reporter)

Comment 12

4 years ago
Created attachment 8549579 [details]
log&视频1
(Reporter)

Comment 13

4 years ago
Created attachment 8549581 [details]
the file which cannot send by MS
(Reporter)

Comment 14

4 years ago
Created attachment 8549582 [details]
log&视频4
(Reporter)

Comment 15

4 years ago
Created attachment 8549583 [details]
log&视频2
(Reporter)

Comment 16

4 years ago
Created attachment 8549584 [details]
log&视频5

Comment 17

4 years ago
>  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.
Flags: needinfo?(sync-1)
(Reporter)

Comment 18

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

Comment 19

4 years ago
[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)平台通过蓝牙发送文件正常。
>     
>     当发送端点击要传送的手机时,接收端没有收到任何提示信息而发送端立即提示发送失败。
(Reporter)

Comment 20

4 years ago
hi mozilla:
    non-FirefoxOS can successfully send the same files to the receiver which is android 4.4(MTK)。
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
status-b2g-v2.0: --- → affected
status-b2g-v2.0M: --- → affected
status-b2g-v2.1: --- → affected
status-b2g-v2.2: --- → affected
File Manager version :1.0-beta2.20150115.
(Reporter)

Comment 23

4 years ago
hi mozilla:
    your steps are correct

Comment 24

4 years ago
Hi Shally,
I do not understand, you said you can reproduce. However the rate is 0/5? Can you repo or cannot?
Flags: needinfo?(lixia)
QA Whiteboard: [COM=Bluetooth]
(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.
Flags: needinfo?(lixia) → needinfo?(jocheng)

Comment 26

4 years ago
Hi Ben,
It seems to be generic issue. Could you help to check again? Thanks!
Flags: needinfo?(sync-1)
Flags: needinfo?(jocheng)
Flags: needinfo?(btian)

Updated

4 years ago
Flags: needinfo?(btian)
Summary: [FFOS2.0][Woodduck][BT]cannot send some unsupported format files via BT → cannot send some unsupported format files via BT

Updated

4 years ago
Component: Gaia::Bluetooth File Transfer → Bluetooth

Comment 27

4 years ago
Will will help on this bug. Assign owner to him.
Assignee: nobody → wiwang
(Reporter)

Comment 28

4 years ago
hi mozilla:
    any update so far?
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."
Will, please update your experiment results.
(Assignee)

Comment 32

3 years ago
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!
Flags: needinfo?(sync-1)
(Reporter)

Comment 33

3 years ago
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?
(Reporter)

Comment 34

3 years ago
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手机通过蓝牙传送文件
(Assignee)

Comment 35

3 years ago
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.
Flags: needinfo?(sync-1)
(Assignee)

Comment 36

3 years ago
Please leave your comment if needed, thanks!
Flags: needinfo?(sync-1)
(Reporter)

Comment 37

3 years ago
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
(Assignee)

Comment 38

3 years ago
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!
Flags: needinfo?(sync-1)
(Assignee)

Updated

3 years ago
Flags: needinfo?(sync-1)
(Reporter)

Comment 39

3 years ago
Created an attachment (id=1152450)
 MimeType in android
(Reporter)

Comment 40

3 years ago
Created an attachment (id=1152450)
 MimeType in android
(Reporter)

Comment 41

3 years ago
Created attachment 8559602 [details]
MimeType in android

Created an attachment (id=1152450)
 MimeType in android
(Reporter)

Comment 42

3 years ago
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.
(Assignee)

Comment 43

3 years ago
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?
(Reporter)

Comment 44

3 years ago
hi mozilla:
    Can you tell me what you design to solve this problem ?
Flags: needinfo?(wiwang)
(Assignee)

Comment 45

3 years ago
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?
Flags: needinfo?(wiwang)
(Assignee)

Comment 46

3 years ago
Hi Dominic

from my comment 45,
If any, may you have any comment/correction for this?
thanks for your help!
Flags: needinfo?(dkuo)

Comment 47

3 years ago
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?
Flags: needinfo?(dkuo)

Updated

3 years ago
Flags: needinfo?(wiwang)
(Assignee)

Comment 48

3 years ago
Hi reporter

please reply comment 45,

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

thanks!
Flags: needinfo?(wiwang)
(Assignee)

Comment 49

3 years ago
(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!

Updated

3 years ago
Flags: needinfo?(chen.ding)
(Reporter)

Comment 50

3 years ago
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.

Updated

3 years ago
Flags: needinfo?(wiwang)

Updated

3 years ago
Blocks: 1054172, 1107999
blocking-b2g: --- → backlog
(Assignee)

Updated

3 years ago
Flags: needinfo?(wiwang)

Comment 51

3 years ago
(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!
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Flags: needinfo?(sync-1)
Flags: needinfo?(chen.ding)
Resolution: --- → WORKSFORME
blocking-b2g: backlog → ---
tracking-b2g: --- → backlog
You need to log in before you can comment on or make changes to this bug.