Gallery screen goes blank during BT file transfer

RESOLVED FIXED in Firefox 24

Status

Firefox OS
Bluetooth
--
major
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: Greg Grisco, Assigned: ericchou)

Tracking

unspecified
1.1 QE3 (26jun)
ARM
Gonk (Firefox OS)
Bug Flags:
in-moztrap +

Firefox Tracking Flags

(blocking-b2g:leo+, firefox22 wontfix, firefox23 wontfix, firefox24 fixed, b2g18 fixed, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 wontfix, b2g-v1.1hd affected)

Details

(Whiteboard: [CR 488550][fixed-in-birch])

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

5 years ago
1. from Settings/Bluetooth, pair device with another BT device
2. from Gallery, attempt to transfer photo via bluetooth to device paired in step 1.

At this point, do not accept the BT transfer on the receiving end

3. from Gallery, select another photo and attempt to transfer photo via bluetooth to same paired device.

Results: The screen goes blank on the sending device and remains that way until original transfer is accepted on the receiving side.
(Reporter)

Updated

5 years ago
blocking-b2g: --- → leo?

Comment 1

5 years ago
Casey, does this one perhaps just need an existing transfer progress bar? Hoping for the easy answer here, but defer to your good experience and judgment.
Flags: needinfo?(kyee)

Updated

5 years ago
Flags: needinfo?(kyee) → needinfo?(rmacdonald)
Hi Greg - Out of about 5 attempts, I had the blank screen once. Typically it just closed the bluetooth dialog and return to the previous view, which is good.

However, there was one thing missing. On the page 12 of the current transfer patterns doc, (https://mozilla.box.com/s/3br18ke7tj0x1s5vj5tv), when the user initiates the transfer, a banner is displayed with an upload icon, the file name and the string, "Upload started". This signals to the user that the transfer has been initiated.

Should this be filed as a separate bug?

- Rob
Flags: needinfo?(rmacdonald)

Updated

5 years ago
Assignee: nobody → mshiao

Updated

5 years ago
blocking-b2g: leo? → leo+
(Reporter)

Comment 3

5 years ago
(In reply to Rob MacDonald [:robmac] from comment #2)
> Hi Greg - Out of about 5 attempts, I had the blank screen once. Typically it
> just closed the bluetooth dialog and return to the previous view, which is
> good.
> 

Are you saying that correct behavior is to not allow the second transfer due to first one being in-progress?  If that's the case, I think the user needs to have some feedback.

> However, there was one thing missing. On the page 12 of the current transfer
> patterns doc, (https://mozilla.box.com/s/3br18ke7tj0x1s5vj5tv), when the
> user initiates the transfer, a banner is displayed with an upload icon, the
> file name and the string, "Upload started". This signals to the user that
> the transfer has been initiated.
> 
> Should this be filed as a separate bug?
> 

To me it sounds like it should be filed as a separate bug.
Flags: needinfo?(rmacdonald)
(In reply to Greg Grisco from comment #3)
> (In reply to Rob MacDonald [:robmac] from comment #2)
> > Hi Greg - Out of about 5 attempts, I had the blank screen once. Typically it
> > just closed the bluetooth dialog and return to the previous view, which is
> > good.
> > 
> Are you saying that correct behavior is to not allow the second transfer due
> to first one being in-progress?  If that's the case, I think the user needs
> to have some feedback.

I'm terribly sorry, Greg, but I misunderstood the original bug so please disregard comment 3. This is a valid error and needs to be fixed. The expected behaviour is that the second item should be queued until the first file is either accepted or rejected. Once the initial transfer is complete (whether it succeeds or fails), the second transfer prompt is displayed.

Have I answered the question this time? If not, please flag me. And sorry for the confusion!
Flags: needinfo?(rmacdonald)

Comment 5

5 years ago
Receiving the below error state when issuing transfer request. 

I/Gonk    (  108): dbus_func_args_timeout_valist: D-Bus error in GetServiceAttributeValue: org.bluez.Error.Failed (GetServiceAttribute Failed)

Occurs in latest pvt build.  Also tried earlier build from 2013-06-01-07-02-10 and getting same result.

Pulling in Eric Chou and Gina Yeh for assistance.
Flags: needinfo?(gyeh)
Flags: needinfo?(echou)
(Assignee)

Comment 6

5 years ago
I can reproduce this easily. 

This is a regression of bug 860166. Currently Gecko Bluetooth would not fire DOM Request onerror event even when the connecting process fails. I'll handle this.

This may also happen in v1.0.1, not sure if we can still uplift, though.
Assignee: mshiao → echou
Component: Gaia::Gallery → Bluetooth
Flags: needinfo?(echou)

Comment 7

5 years ago
removing need info request from Gina
Flags: needinfo?(gyeh)
(Assignee)

Comment 8

5 years ago
Created attachment 760786 [details] [diff] [review]
patch 1: v1: Fire DOMRequest.onerror event when Bluetooth*Manager.Connect() fails

* Fire DOMRequest.onerror event when Bluetooth*Manager.Connect() fails
Attachment #760786 - Flags: review?(gyeh)
Comment on attachment 760786 [details] [diff] [review]
patch 1: v1: Fire DOMRequest.onerror event when Bluetooth*Manager.Connect() fails

Review of attachment 760786 [details] [diff] [review]:
-----------------------------------------------------------------

Agree with Eric. This should be a regression of bug 860166 and we need a patch for v1.0.1.

::: dom/bluetooth/BluetoothOppManager.cpp
@@ +257,5 @@
>  {
>    MOZ_ASSERT(NS_IsMainThread());
>  
> +  BluetoothService* bs = BluetoothService::Get();
> +  if (!bs) {

Shall we also check sInShutdown here?
Attachment #760786 - Flags: review?(gyeh) → review+
(Assignee)

Comment 10

5 years ago
Created attachment 760809 [details] [diff] [review]
patch 1: final: Fire DOMRequest.onerror event when Bluetooth*Manager.Connect() fails

* nit picked
Attachment #760786 - Attachment is obsolete: true
(Assignee)

Updated

5 years ago
Whiteboard: [CR 488550] → [CR 488550][fixed-in-birch]
(Assignee)

Comment 12

5 years ago
Created attachment 760819 [details] [diff] [review]
patch 1: for b2g18

b2g18-specific patch
https://hg.mozilla.org/mozilla-central/rev/850160a3c34c
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
https://hg.mozilla.org/releases/mozilla-b2g18/rev/8d0562d20324
status-b2g18: --- → fixed
status-b2g18-v1.0.0: --- → wontfix
status-b2g18-v1.0.1: --- → wontfix
status-b2g-v1.1hd: --- → affected
status-firefox22: --- → wontfix
status-firefox23: --- → wontfix
status-firefox24: --- → fixed
Target Milestone: --- → 1.1 QE3

Updated

5 years ago
Flags: in-moztrap?

Updated

5 years ago
Flags: in-moztrap? → in-moztrap+

Comment 15

5 years ago
Added Bluetooth Suite Test Case #8755 [Bluetooth] Verify a blank screen is not displayed while waiting for approval of a Bluetooth file transfer
You need to log in before you can comment on or make changes to this bug.