1088017 - User not able to accept multiple files sent over BT

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Bluetooth, defect)

Description

[Stephanie Ouillon [:arroway] (needinfo me)]

Build Information
Gaia-Rev        1e48e3e40e0780c0cd07a3457e5fe2efeeb542d1
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/09fb60a37850
Build-ID        20141023001201
Version         34.0
Device-Name     flame
Base image: ***Please update this field to say if you're running the v180 or the v188 base image***


Description
When a file is transfered by bluetooth from the gallery, the receiver is prompted to confirm he wants to receive it.
If the sender sends another file before the first file has been completely transfered, the receiver is not prompted for accepting the second file.

Steps to Reproduce
1. In the sender phone: share a file with bluetooth from the gallery app.
2. On the receiver phone: confirm you want to receive the file
3. On the sender phone, and before the first transfer is completed: share another file

Expected Results
The receiver should be prompted to accept the second file, after the first transfert is completed.

Actual Results
The receiver is not prompted.

Other Notes
A user can be flooded maliciously or not by a device he has trusted for one file transfer.

Reproduction Frequency: always

Comment 1

[Ben Tian (inactive)]

ni? UX Jenny to comment.

I agree that accepting once for all file has potential flooding risk, but accepting once for each file also introduces redundant interruption if user receives many files (say tens of files) sent once from sender. Confirmation notifications would keep interrupting/annoying user before all files are received.

Comment 2

[Stephanie Ouillon [:arroway] (needinfo me)]

(In reply to Ben Tian [:btian] from comment #1)
> 
> I agree that accepting once for all file has potential flooding risk, but
> accepting once for each file also introduces redundant interruption if user
> receives many files (say tens of files) sent once from sender.

You're right, but for the case I've been testing, the sender is sending one file at the time, several times, not multiple files once. 
Also, I didn't test it, but it looks like it's also possible to end up in a situation where:
1. device 1 sends a file to device 2 (user 2 is asked for confirmation)
2. device 3 sends a file to device 2 while device 2 is receiving a file (user 2 is not prompted)

Comment 3

[Ben Tian (inactive)]

(In reply to Stephanie Ouillon [:arroway] from comment #2)
> You're right, but for the case I've been testing, the sender is sending one
> file at the time, several times, not multiple files once. 

This case is treated the same as 'multiple files once' in gecko since 'multiple files once' is actually queued for transfer one by one.

I'll let Jenny comment the desired UX behavior to see what we can do to improve.

> Also, I didn't test it, but it looks like it's also possible to end up in a
> situation where:
> 1. device 1 sends a file to device 2 (user 2 is asked for confirmation)
> 2. device 3 sends a file to device 2 while device 2 is receiving a file
> (user 2 is not prompted)

No, this case would prompt for device 3 since it's another connection.

Comment 4

[Tony Chung [:tchung]]

can we get qawanted if this reproduces on 2.0?  to determine if this is a regression or not.

Comment 5

[Chris Kreinbring [:CKreinbring]]

The bug repros on Flame 2.2, 2.1, 2.0 and 2.0 base engineering with shallow flash.
Actual result: While sending a large file over Bluetooth, the sending device can add multiple files to transfer without needing the receiving file to approve the transfer.  The receiving user will not notice until either they open the notification screen or the next file finishes transferring.

Flame 2.2
BuildID: 20141028061150
Gaia: 75e10bb632b1e4a47493d0a66bc32fb74249c57f
Gecko: ab91b8407313
Platform Version: 36.0a1
Firmware Version: V188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Flame 2.1
BuildID: 20141028051549
Gaia: d26ff7da07e910e55855db3d6e1583592e81e797
Gecko: 737ab5ff452c
Platform Version: 34.0
Firmware Version: V188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Flame 2.0
BuildID: 20141028112249
Gaia: 9f5b6f025e528fabfcc068782cb9b492cb51a7f9
Gecko: 19219023440c
Platform Version: 32.0
Firmware Version: V188
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Flame 2.0 base
BuildID: 20141016183911
Gaia: 8c5c956ee6909408e29f375cc7d843a03d92f3d8
Gecko: 
Platform Version: 32.0
Firmware Version: V188
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 6

[Jenny Lee]

Hi all, please see Bug 1066461 attachment 8521308 [details] for spec addressing issue described in this bug. Each transfer can include one or more files, user will only have to confirm once. Note that user has to confirm whether or not to accept file(s) before each different transfers.Thanks!

Comment 7

[Stephanie Ouillon [:arroway] (needinfo me)]

(In reply to Jenny Lee from comment #6)
> Each transfer can include one or
> more files, user will only have to confirm once. Note that user has to
> confirm whether or not to accept file(s) before each different
> transfers.

Sounds good to me

Comment 9

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

(In reply to Jenny Lee (PTO 3/26-4/10) from comment #6)
> Hi all, please see Bug 1066461 attachment 8521308 [details] for spec
> addressing issue described in this bug. Each transfer can include one or
> more files, user will only have to confirm once. Note that user has to
> confirm whether or not to accept file(s) before each different
> transfers.Thanks!

Hi Jenny, 

Once we revise the description on the confirmation dialog, there is no incoming file name/size on it.
I would like to let you know the situation. If you think it's acceptable, I can start to improve the UX changed. Thanks.

Comment 10

[Jenny Lee]

(In reply to Ian Liu [:ianliu] from comment #9)
> (In reply to Jenny Lee (PTO 3/26-4/10) from comment #6)
> > Hi all, please see Bug 1066461 attachment 8521308 [details] for spec
> > addressing issue described in this bug. Each transfer can include one or
> > more files, user will only have to confirm once. Note that user has to
> > confirm whether or not to accept file(s) before each different
> > transfers.Thanks!
> 
> Hi Jenny, 
> 
> Once we revise the description on the confirmation dialog, there is no
> incoming file name/size on it.
> I would like to let you know the situation. If you think it's acceptable, I
> can start to improve the UX changed. Thanks.

Yes I'm aware of the change, please go ahead with the implementation, thanks!

Comment 11

[Jenny Lee]

Attachment: [Settings] Bluetooth v1.21.pdf

See attached for the latest spec. Thanks =)

Comment 12

[GitHub Autolander Bot]

Attachment: [gaia] ian-liu:bluetooth/bug1088017_revise_description_for_incoming_file_confirmation_dialog > mozilla-b2g:master

Comment 13

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

Comment on attachment 8602552 [details] [review]
[gaia] ian-liu:bluetooth/bug1088017_revise_description_for_incoming_file_confirmation_dialog > mozilla-b2g:master

The WIP toward new spec. definition. Per spec. definition, the notification of each transfer completed will be changed in these cases.

1. File could not be received (failed with any reason, except manually cancel)
2. File transfer cancelled    (manually cancel file sending)
3. File(s) transfer cancelled (manually cancel file(s) receiving)

In failed case, Gaia might to reference error message for define notification. Because it is risk to use filename to match with each transfer completed task. So that I would like to request error message/reason/info. from the 'bluetooth-opp-transfer-complete' system message.

Ben, I would like to request platform support here. How do you think the proposal? Thanks.

Comment 14

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

Per comment 13, ni from Ben.

Comment 15

[Ben Tian (inactive)]

(In reply to Ian Liu [:ianliu] from comment #13)
> The WIP toward new spec. definition. Per spec. definition, the notification
> of each transfer completed will be changed in these cases.
> 
> 1. File could not be received (failed with any reason, except manually
> cancel)
> 2. File transfer cancelled    (manually cancel file sending)
> 3. File(s) transfer cancelled (manually cancel file(s) receiving)

Gecko can tell these three conditions.

> In failed case, Gaia might to reference error message for define
> notification. Because it is risk to use filename to match with each transfer
> completed task. So that I would like to request error message/reason/info.
> from the 'bluetooth-opp-transfer-complete' system message.

Which error reasons/info do you need?

Comment 16

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

(In reply to Ben Tian [:btian] from comment #15)
> (In reply to Ian Liu [:ianliu] from comment #13)
> > The WIP toward new spec. definition. Per spec. definition, the notification
> > of each transfer completed will be changed in these cases.
> > 
> > 1. File could not be received (failed with any reason, except manually
> > cancel)
> > 2. File transfer cancelled    (manually cancel file sending)
> > 3. File(s) transfer cancelled (manually cancel file(s) receiving)
> 
> Gecko can tell these three conditions. 
> Which error reasons/info do you need?

Now, the 'bluetooth-opp-transfer-complete' system message is providing some information as following.

I/GeckoConsole( 7952): Content JS LOG: _onTransferComplete(): transferInfo = {"address":"70:56:81:a5:c6:08","success":false,"received":false,"fileName":"IMG_5692-1.jpg","fileLength":589752,"contentType":"image/jpeg"}

How about we have a property 'unsuccessReason' to distinguish two major conditions. My naming would not be good! Please revise it, if you have a better name. And any concern of error definition, we can have discussion on them.

'unsuccessReason' could be:
* socketDisconnected/unknowError/...?
* manuallyCancel

For above condition 2 and 3, Gaia is able to check 'received' property. Therefore, I think two reasons is enough to complete the three.

Comment 17

[Ben Tian (inactive)]

(In reply to Ian Liu [:ianliu] from comment #16)
> How about we have a property 'unsuccessReason' to distinguish two major
> conditions. My naming would not be good! Please revise it, if you have a
> better name. And any concern of error definition, we can have discussion on
> them.

Naming is not a problem. I'll define and let you know.

> 'unsuccessReason' could be:
> * socketDisconnected/unknowError/...?
> * manuallyCancel

The list is what I'm asking. I need it to insert corresponding reason assignment in gecko. Any draft proposal?

Comment 18

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

'unsuccessReason' could be:
* socketDisconnected            (The error is due to socket connection.)
* manuallyCancel                (The error is due to our cancellation.)
* manuallyCancelFromRemote      (The error is due to remoted device cancellation.)
* storageUnavailable            (The error is due to our storage unavailable.)
* storageUnavailableFromRemote  (The error is due to remoted device storage unavailable.)
* unknowError                   (Unknown error causes the fail.)

Ben, Not sure above enumeration and explanation is helpful. Maybe other reasons I have never thought. If platform is able to distinguish different unsuccessful reason in detail, I'm happy to see them with different reason. Gaia just greps what reason is defined in our user story.

Comment 19

[Ben Tian (inactive)]

(In reply to Ian Liu [:ianliu] from comment #18)
> * manuallyCancelFromRemote      (The error is due to remote device
> cancellation.)

This case depends on whether remote device informs gecko before disconnection. For example, current gecko simply disconnects when user cancels transfer w/o informing remote device.

> * storageUnavailable            (The error is due to our storage
> unavailable.)

This case involves following two conditions. I'll confirm whether we can beware of unavailable storage correctly.
1) device storage becomes unavailable during transfer.
2) as a receiver, device storage is unavailable to create file before transfer.

> * storageUnavailableFromRemote  (The error is due to remote device storage
> unavailable.)

This case is difficult to tell as remote device probably disconnects directly w/o informing gecko.

Comment 20

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

(In reply to Ben Tian [:btian] from comment #19)
> (In reply to Ian Liu [:ianliu] from comment #18)
> > * manuallyCancelFromRemote      (The error is due to remote device
> > cancellation.)
> 
> This case depends on whether remote device informs gecko before
> disconnection. For example, current gecko simply disconnects when user
> cancels transfer w/o informing remote device.

Per current UX spec., 'manuallyCancel' is enough to figure out transfer cancelled via a user. 'manuallyCancelFromRemote' is optional.

> > * storageUnavailableFromRemote  (The error is due to remote device storage
> > unavailable.)
> 
> This case is difficult to tell as remote device probably disconnects
> directly w/o informing gecko.

Per spec. definition, we have no urgent to identify failed reason for the two cases('storageUnavailable', 'storageUnavailableFromRemote').

Comment 21

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

Leave assigned since I'm working on other issue. Will go back here while Gecko is able to provide error reason.

Comment 23

[BMO Automation]

Firefox OS is not being worked on