Closed
Bug 1134438
Opened 10 years ago
Closed 7 years ago
[Bluetooth][Feature Request] - When tapping on a failed transfer notification the user is not presented with the option to resend the file.
Categories
(Firefox OS Graveyard :: Bluetooth, defect)
Tracking
(tracking-b2g:+, b2g-master affected)
People
(Reporter: jmitchell, Unassigned)
References
Details
Description:
It would be nice to be able to resend failed file transfers with a single button press. Currently when a file transfer fails we are given a notification that the file could not be sent. Clicking on the notification will only clear it from the notification menu. Rather than having to re-launch the app, re-find the media, tap the share button, find the device, and re-transfer it, it would be very time and step saving if the user could just attempt to resend the file via an error page with this option
Repro Steps:
1) Update a Flame to 20150218010226
2) Send a Media File to another device via Bluetooth
3) During the transfer turn on airplane mode on the receiving device (to replicate a send failure)
4) Pull down notifications and tap on the file could not be sent notification
Actual:
Notification clears, no resend option is given
Expected:
Resend option will be given
Environmental Variables:
Device: Flame 3.0 (KK - Nightly - Full Flash - 319mem)
Build ID: 20150218010226
Gaia: 82f286f10a41aab84a0796c89fbefe67b179994b
Gecko: 9696d1c4b3ba
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 38.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0
Reporter | ||
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Comment 1•10 years ago
|
||
NI on component owner, this is a feature request.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga) → needinfo?(twen)
Comment 2•10 years ago
|
||
NI BT developer. Hi Jamin, please help with this feature request.
Flags: needinfo?(twen) → needinfo?(jaliu)
Comment 3•10 years ago
|
||
ni? UX Jenny to comment instead.
Jenny, please comment whether to adopt the UX requirement and, if yes, provide corresponding UX spec for implementation.
Flags: needinfo?(jaliu) → needinfo?(jelee)
Updated•10 years ago
|
blocking-b2g: --- → backlog
tracking-b2g:
--- → +
Hi Ben,
Got a few question :)
1. What if by the time user taps on the "failed to send" notification, BT is off and the receiving device is out of range, is it possible to know the above two status and inform user right after she taps the notification? I'm assuming it would take some time to scan?
2. Is it possible to enable "resend" function by condition? For example, if BT is ON and receiving device is still in range, show "tap to resend" on notification second line; otherwise, disable the "resend" function.
Thanks!
Flags: needinfo?(jelee)
Comment 6•10 years ago
|
||
Jenny,
(In reply to Jenny Lee from comment #5)
> 1. What if by the time user taps on the "failed to send" notification, BT is
> off and the receiving device is out of range, is it possible to know the
> above two status and inform user right after she taps the notification? I'm
> assuming it would take some time to scan?
1) Gaia and gecko know BT is off.
2) Gecko doesn't know whether receiver is out-of-range but gets connection failure only. If BT is on, gaia triggers gecko to connect to receiver directly (no re-scan). Sender gets connection failure if receiver becomes out-of-range, turns BT off, or refuses incoming connection.
> 2. Is it possible to enable "resend" function by condition? For example, if
> BT is ON and receiving device is still in range, show "tap to resend" on
> notification second line; otherwise, disable the "resend" function.
It depends on which conditions. Again, gecko cannot tell whether receiver is still in range or not.
Hi Ben,
Thanks for the answer!
Overall I think it's a good idea to have the resend function, and that's definitely something I would like to have for better UX. However due to the ongoing v3 process which might have structure change, it is unclear at this point how to achieve it. I will look into this design requirement again once v3 direction is settled. Thanks!
Assignee | ||
Updated•10 years ago
|
blocking-b2g: backlog → ---
Comment 8•9 years ago
|
||
Harly,
Per comment 7, do we still intend to have this feature?
Flags: needinfo?(hhsu)
Comment 9•9 years ago
|
||
Currently, the specific features/ functions haven't been defined; therefore, I don't think this feature is intended till we have a specific plan.
Flags: needinfo?(hhsu)
Comment 10•7 years ago
|
||
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•