Closed Bug 868303 Opened 9 years ago Closed 4 years ago

[b2g-bluetooth] When remote cancels a file transfer, no response after confirmation

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(tracking-b2g:backlog, b2g18+ affected)

RESOLVED WONTFIX
tracking-b2g backlog
Tracking Status
b2g18 + affected

People

(Reporter: gyeh, Unassigned)

References

Details

(Whiteboard: dupeme)

STR:
0. Pair with another device
1. Send a file from remote
2. Receive file request is shown on system tray
3. Remote cancels the file transfer
4. Pull down status bar and press "Receive File?"
5. Choose "Transfer"

Expected result:
- File transfer failed should be shown

Actual result:
- No response
Nominated as tef? since no response is not a good user experience. We should notify users that the transfer is completed but failed.
blocking-b2g: --- → tef?
We definitely should let users know that the file transfer session was closed. Just talked to Ian and we decided to solve it on Gaia side.
Component: Bluetooth → Gaia::Bluetooth File Transfer
We need UX's input for improving the message. We have some suggestion as following.

After remote canceled the file transfer:

Expected result:

Suggestion A:
(Status: Receive file request is shown on system tray)
* Clear receive file request on system tray *
- Show file transfer failed on system tray

(Status: The dialog of receive file request is shown)
- Close the dialog of receive file request immediately
- Show file transfer failed on system tray

=======================================================

Suggestion B:
(Status: Receive file request is shown on system tray)
* Clear receive file request on system tray *
- Show a message "Session Timeout.." on system tray
- Show file transfer failed on system tray

(Status: The dialog of receive file request is shown)
- Close the dialog of receive file request immediately
- Pop out a dialog with some message "Session Timeout.."
- Show file transfer failed on system tray

In side of implementation of notification center, we cannot modify the message which was already shown. So, the * scenario may not be able to be implemented. We should have some discussion for refining notification component.
Assignee: nobody → iliu
Flags: needinfo?(firefoxos-ux-bugzilla)
Seems like a work to do and impact on the UX, I'd suggest we don't take this for 1.0.1
Whiteboard: [tef-triage]
Yes, this is late work for v1.0.1 and is probably in a user story for v1.1 -- but this also sounds like it should exist already in bug tracking the bluetooth implementation.
blocking-b2g: tef? → leo?
Whiteboard: [tef-triage] → [tef-triage] dupeme
Assigning from general firefoxos-ux to Rob. I believe we may have existing patterns that address this but am not sure.
Flags: needinfo?(firefoxos-ux-bugzilla)
Flags: needinfo?(rmacdonald)
blocking-b2g: leo? → -
tracking-b2g18: --- → +
(In reply to Ian Liu [:ianliu] from comment #3)
> We need UX's input for improving the message. We have some suggestion as
> following.
> 
> After remote canceled the file transfer:
> 
> Expected result:
> 
> Suggestion A:
> (Status: Receive file request is shown on system tray)
> * Clear receive file request on system tray *
> - Show file transfer failed on system tray
> 
> (Status: The dialog of receive file request is shown)
> - Close the dialog of receive file request immediately
> - Show file transfer failed on system tray

Ian, this would be my preferred option. But rather than showing the string "File transfer failed", we should indicate the reason. If we can get the string, "File transfer cancelled by user" might work.


> In side of implementation of notification center, we cannot modify the
> message which was already shown. So, the * scenario may not be able to be
> implemented. We should have some discussion for refining notification
> component.

Can you please confirm this and send me a needs info? Also, do we need screens for this or does the description suffice?

Thanks!
Rob
Flags: needinfo?(rmacdonald)
Whiteboard: [tef-triage] dupeme → dupeme
Hi Rob,

Sorry to give you the feedback late for the late work. Since Web Notification API is ready to work. We are able to use tag property to update the later notification. I would like to add the bug in backlog. And will have discussion with Omega who is the owner of Bluetooth component. Beside, we might need to reach the remote user rejection from our Bluetooth component too.
Flags: needinfo?(jcheng)
Hi Joe, I will need your plan for the issue here. Thanks.
let's 1.5? so it gets into triage
blocking-b2g: - → 1.5?
Flags: needinfo?(jcheng)
Duplicate of this bug: 991909
feature, move to backlog
blocking-b2g: 2.0? → backlog
blocking-b2g: backlog → ---
Assignee: iliu → nobody
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.