876823 - Gallery screen goes blank during BT file transfer

Status: RESOLVED FIXED

Description

[Greg Grisco]

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.

Comment 1

[Stephany Wilkes]

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.

Comment 2

[Rob MacDonald [:robmac]]

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

Comment 3

[Greg Grisco]

(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.

Comment 4

[Rob MacDonald [:robmac]]

(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!

Comment 5

[Mark Shiao]

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.

Comment 6

[Eric Chou [:ericchou] [:echou]]

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.

Comment 7

[Mark Shiao]

removing need info request from Gina

Comment 8

[Eric Chou [:ericchou] [:echou]]

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

Comment 9

[Gina Yeh [:gyeh] [:ginayeh]]

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?

Comment 10

[Eric Chou [:ericchou] [:echou]]

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

* nit picked

Comment 11

[Eric Chou [:ericchou] [:echou]]

https://hg.mozilla.org/projects/birch/rev/850160a3c34c

Comment 12

[Eric Chou [:ericchou] [:echou]]

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

b2g18-specific patch

Comment 13

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/850160a3c34c

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g18/rev/8d0562d20324

Comment 15

[:CSchmoeckel]

Added Bluetooth Suite Test Case #8755 [Bluetooth] Verify a blank screen is not displayed while waiting for approval of a Bluetooth file transfer