1029037 - [B2G][Bluetooth]Screen transitioning while reciving a pair request will not close the pairing dialog normally.

Status: VERIFIED FIXED

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

Description

[Josh Schmitt [Joshs]]

Attachment: BluetoothPairConfirmation_log.txt

Description:
Transitioning on the DUT while a bluetooth pair request occurs the pair request page is stuck at the top of the screen.

Repro Steps:
1) Update a Flame to 20140623000201
2) Open Setting app and turn on Bluetooth
3) On the DUT turn the visibiity on
4) With a 2nd device connect to the DUT
5) With the DUT immedietly do screen transitions e.g. open setting, press home button from app

Actual:
Pair request page is not fully shown.

Expected:
The pair request is shown correctly when transitioning.

Environmental Variables:
Device: Flame
Build ID: 20140623000201
Gaia: 729f214b887ce8efe7d870145d31acb2c6427817
Gecko: 117ba3eda4d2
Version: 32.0a2 (2.0) 
Firmware Version: v122

User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Notes:
Repro frequency: 100%
See attached: screenshot, logcat,

Comment 1

[Josh Schmitt [Joshs]]

Attachment: 2014-06-23-13-34-02.png

Comment 2

[Josh Schmitt [Joshs]]

Adding qawanted to test other branches/builds

Comment 3

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Hi Ian,
Do you have any idea why pairing request dialog is not fully showing?

Comment 4

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

The dialog is maintained via attention screen. There is a mini-bar style while the attention screen is showing and a user click home button. It will make the style of attention screen to be mini-bar style. In case of pairing dialog, the expected result is closing the dialog immediately after a user clicked home button.

Hi Josh, will the pairing dialog be closed finally after a user clicked home button?

Comment 5

[Josh Schmitt [Joshs]]

(In reply to Ian Liu [:ianliu] from comment #4)
> The dialog is maintained via attention screen. There is a mini-bar style
> while the attention screen is showing and a user click home button. It will
> make the style of attention screen to be mini-bar style. In case of pairing
> dialog, the expected result is closing the dialog immediately after a user
> clicked home button.
> 
> Hi Josh, will the pairing dialog be closed finally after a user clicked home
> button?

If the user presses the Home button the dialog box does not disappear.

Comment 6

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

I'm not able to reproduce it. The dialog disappear normally while presses the home button. Is there any repro step missed in description?

Gaia      512f288e4871990a2f412babcc63fc3ce0287867
Gecko     https://hg.mozilla.org/mozilla-central/rev/afa67a2f7905
BuildID   20140629160201
Version   33.0a1
ro.build.version.incremental=108
ro.build.date=Tue Jun 10 19:40:40 CST 2014

Comment 7

[Josh Schmitt [Joshs]]

(In reply to Ian Liu [:ianliu] from comment #6)
> I'm not able to reproduce it. The dialog disappear normally while presses
> the home button. Is there any repro step missed in description?
> 
> Gaia      512f288e4871990a2f412babcc63fc3ce0287867
> Gecko     https://hg.mozilla.org/mozilla-central/rev/afa67a2f7905
> BuildID   20140629160201
> Version   33.0a1
> ro.build.version.incremental=108
> ro.build.date=Tue Jun 10 19:40:40 CST 2014

The bug does not need the home button to be pressed for it to occur, anything that transitions the screen like loading Settings app, Music app etc.

Once the dialog box is in the bug state, pressing the Home button does not dismiss the dialog box.

1. With a 2nd device try to pair with the DUT
2. Immediately load apps on the DUT while the 2nd one sends pair request.

Comment 8

[Chris Kreinbring [:CKreinbring]]

The bug repros on Flame 2.0 and Buri 2.0

Flame 2.0
Build ID: 20140703000248
Gaia: 7ad00b0bd84d5d97e0801e3b3ceaac33fcd90e05
Gecko: e87f7b398fce
Version: 32.0a2 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Buri 2.0
Build ID: 20140703064557
Gaia: 26f82bf95d237272e66955bbca3323ccf8fcb74a
Gecko: 747a8c44ff44
Platform Version: 32.0a2 (2.0)
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Actual result: Receiving a Bluetooth pairing request while transitioning between screens can show the Pair/Cancel buttons where the status bar is located.

--------------------------------------------------------------------------------------------------------

The bug does not repro on Flame 1.4

Build ID: 20140630000201
Gaia: aa896d5db1b4929f3bf31a0f4bb7de50530222a8
Gecko: 8cba60bc12ef
Platform Version: 30.0
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Actual result:  Receiving a Bluetooth pairing request while transitioning between screens shows the request page fully while the transition completes in the background.

Comment 9

[Joshua Mitchell (Inactive)]

Nomming for 2.0 blocker - bug looks very bad and will be easily identified as a bug by the user, creating a bad user-experience.

Comment 10

[howie [:howie]]

Hi Ian, need your help to look further into this, thanks.

Comment 11

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

Josh, I'm able to reproduce the issue. But it's able to close the pairing dialog while I press home button. The mini attention screen will be disappear after press home button. And the issue is not easy to reproduce for me(Rate: 1/5). Could you please help to record a video for the blocking result(cannot close pairing dialog)? Thanks.

For the solution, I think we might check the dialog status during init(). It should be showing in status bar mode immediately before we start to listener 'resize' event.  It could be a timing issue.

Comment 12

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

Per comment 11, I would like QA team support for standard reproduced steps. And help to make sure the pairing dialog is blocking or not.

Comment 13

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

Hi Alison, could you please help to check comment 12? Thanks.

Comment 14

[Josh Schmitt [Joshs]]

(In reply to Ian Liu [:ianliu] from comment #11)
> Josh, I'm able to reproduce the issue. But it's able to close the pairing
> dialog while I press home button. The mini attention screen will be
> disappear after press home button. And the issue is not easy to reproduce
> for me(Rate: 1/5). Could you please help to record a video for the blocking
> result(cannot close pairing dialog)? Thanks.
> 
> For the solution, I think we might check the dialog status during init(). It
> should be showing in status bar mode immediately before we start to listener
> 'resize' event.  It could be a timing issue.

I am not able to close the pairing dialog if the dialog is at the top of the screen acting as a "notification"

However, once I pulled the pairing dialog down to make it fullscreen I was then able to press the 'Home' button to close the dialog.

I have uploaded a video here:

https://www.youtube.com/watch?v=KUNdLXIPxYY

Comment 15

[Alison Shiue]

I tried on
Gaia      16d99f67c376378df850343667cee43af87c24a6
Gecko     https://hg.mozilla.org/releases/mozilla-aurora/rev/558d378d7364
BuildID   20140708160201
Version   32.0a2

I can reproduce but it is hard for me. (1/10)
The timing to change screen to trigger this issue is not easy.
As Josh mentioned, I could not close the pairing dialog via home button if the dialog is at the top unless pulled the pairing dialog down to make it fullscreen.
But once BT request timeout, the top dialog will disappear.

Comment 16

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

(In reply to Josh Schmitt [Joshs] from comment #0)
> Expected:
> The pair request is shown correctly when transitioning.
> 

I will aim to close the attention dialog in status bar mode after the screen transitions. Because the expected result is not reasonable for me. The transition is coming after the dialog shows. So that, the dialog is changed the style in status bar mode. I think we could have two ways for the solutions. 

1). Close the dialog immediately while it's in status bar mode. (It's low risk for v2.0.)
2). Implement a style for the pairing dialog when it's in status bar mode. (This option is a feature. And might make some inconsistent issue for building block.)

Comment 17

[Omega Feng [:Omega] [:馮於懋]]

Jenny, please help on this, thanks. ;)

Comment 18

[Jenny Lee]

(In reply to Ian Liu [:ianliu] from comment #16)
 
> 1). Close the dialog immediately while it's in status bar mode. (It's low
> risk for v2.0.)
> 2). Implement a style for the pairing dialog when it's in status bar mode.
> (This option is a feature. And might make some inconsistent issue for
> building block.)

Hello Ian, I prefer solution 2 in the long run as it gives user choice of not handling the pairing temporarily (like incoming call or alarm). I will update the design accordingly. For 2.0, let's go for solution 1. Thank you!

Comment 19

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

Jenny, thanks for the expected UX input here quickly. Since the solution 1). is for the blocking issue, I refine the title.

Comment 20

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

Attachment: pull request 21571

Arthur, could you please help to review the patch? The root cause is relative with 'resize' event. There is no 'resize' event coming after addEventListener in Pairview.show(). Thanks.

Comment 21

[Roland Kunkel [:RolandK]]

(In reply to Ian Liu [:ianliu] from comment #12)
> Per comment 11, I would like QA team support for standard reproduced steps.
> And help to make sure the pairing dialog is blocking or not.

Removing QA wanted tag based on comment #14 and comment #15: Video has been attached and STRs are reproducible.

Comment 22

[Arthur Chen [:arthurcc][inactive after 6/30]]

Comment on attachment 8453611 [details] [review]
pull request 21571

I've left a few comments in github mainly focused on the tests, thanks.

Comment 23

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

Comment on attachment 8453611 [details] [review]
pull request 21571

Arthur, thanks for your review effort. I have added some unit tests per your suggestion on GitHub. Will need your review again.

Comment 24

[Arthur Chen [:arthurcc][inactive after 6/30]]

Comment on attachment 8453611 [details] [review]
pull request 21571

Looks good to me, thank you!

Comment 25

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

Since the pr is landed, we can close the issue now.

Gaia/master:  a35527a3e3cd44e2586adbd207da5a36b9407aa6

Comment 26

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

Pull request for 2.0, checking test via TBPL:

https://github.com/mozilla-b2g/gaia/pull/21732

Comment 27

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

Gaia/v2.0:  f3bd238992ea17f9c46004c58e3f0c44421b06ed

Comment 28

[SandKing]

From Comment14 video link
This issue has been verified successfully on Flame2.0&2.1
Verify video:"verify_1029037.mp4".
Rate： 0/20

Flame2.0 build
Gaia-Rev        856863962362030174bae4e03d59c3ebbc182473
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/e40fe21e37f1
Build-ID        20141208000206
Version         32.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141208.035628
FW-Date         Mon Dec  8 03:56:38 EST 2014
Bootloader      L1TC00011880

Flame 2.1 build:
Gaia-Rev        38e17b0219cbc50a4ad6f51101898f89e513a552
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/8b92c4b8f59a
Build-ID        20141205001201
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141205.035305
FW-Date         Fri Dec  5 03:53:16 EST 2014
Bootloader      L1TC00011880

Comment 29

[SandKing]

Attachment: Verfied video: verify_1029037.mp4