1027398 - [Flame] Bluetooth Overlays will show before lockscreen

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)

Description

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Attachment: 2014-06-18-23-37-59.png

Gaia      83844c7679b3b9f6e7f1116c1eeec2d1e7a64eec
Gecko     https://hg.mozilla.org/releases/mozilla-aurora/rev/55679dc2e72b
BuildID   20140618000202
Version   32.0a2
ro.build.version.incremental=108
ro.build.date=Tue Jun 10 19:40:40 CST 2014
Flame

1. turn bluetooth on
2. get the bluetooth pairing overlay
3. hit the power button
4. hit the power button again

Expected: lockscreen
Actual: bluetooth pairing

Note:
1. if the lockscreen is up before the bluetooth overlay then the lockscreen will show as expected.
2. if you look carefully at the screenshot you can see the time through the overlay in the screenshot ( that's why I didn't take a video )

Comment 1

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

qawanted to check 1.4

Comment 2

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

I had this happen with the geolocation overlay for rocketbar as well.  ( first time use of rocketbar )

Comment 3

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #2)
> I had this happen with the geolocation overlay for rocketbar as well.  (
> first time use of rocketbar )

This is another issue.

Comment 4

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

This is a long issue for the pairing dialog. I believe it's able to reproduce from v1.0. Since it's managed via attention screen for a long time, the priority is higher than locked screen. So that we're able to see it after screen is locked. The solution might be two for me.

1. Shell system app provide another property like 'dialog' for window.open? Then, the z-index of the dialog is lower than locked screen. So that app no need to care about screen locked or not.

2. Bluetooth app have to immediately close the dialog itself while screen is locked. Then, it will need to window.open it again while screen is unlocked.

I would like solution 1. Maybe we can move out some system dialogs(system dialog, dialog-overlay) from system app one day. But I'm not sure that it's possible and reasonable for system app.

Alive, do you have any suggestion here? Thanks.

Comment 5

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Ian Liu [:ianliu] from comment #4)
> This is a long issue for the pairing dialog. I believe it's able to
> reproduce from v1.0. Since it's managed via attention screen for a long
> time, the priority is higher than locked screen. So that we're able to see
> it after screen is locked. The solution might be two for me.
> 
> 1. Shell system app provide another property like 'dialog' for window.open?
> Then, the z-index of the dialog is lower than locked screen. So that app no
> need to care about screen locked or not.
> 
> 2. Bluetooth app have to immediately close the dialog itself while screen is
> locked. Then, it will need to window.open it again while screen is unlocked.
> 
> I would like solution 1. Maybe we can move out some system dialogs(system
> dialog, dialog-overlay) from system app one day. But I'm not sure that it's
> possible and reasonable for system app.
> 
> Alive, do you have any suggestion here? Thanks.

For 1 if you want
window.open('xxx.html', 'xxx', 'attention-but-not-that-attention') ? No, I don't think this makes sense.

Comment 6

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Alive Kuo [:alive][NEEDINFO!][OOO from 6/23 until 6/30] from comment #5)
> (In reply to Ian Liu [:ianliu] from comment #4)
> > This is a long issue for the pairing dialog. I believe it's able to
> > reproduce from v1.0. Since it's managed via attention screen for a long
> > time, the priority is higher than locked screen. So that we're able to see
> > it after screen is locked. The solution might be two for me.
> > 
> > 1. Shell system app provide another property like 'dialog' for window.open?
> > Then, the z-index of the dialog is lower than locked screen. So that app no
> > need to care about screen locked or not.
> > 
> > 2. Bluetooth app have to immediately close the dialog itself while screen is
> > locked. Then, it will need to window.open it again while screen is unlocked.
> > 
> > I would like solution 1. Maybe we can move out some system dialogs(system
> > dialog, dialog-overlay) from system app one day. But I'm not sure that it's
> > possible and reasonable for system app.
> > 
> > Alive, do you have any suggestion here? Thanks.
> 
> For 1 if you want
> window.open('xxx.html', 'xxx', 'attention-but-not-that-attention') ? No, I
> don't think this makes sense.

The concern here is this is a API pollution so if you want please go to webapi.
Otherwise we should go (2) or else.

Comment 7

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

Attachment: pull request 20915

Arthur, could you please help to review my pull request? I will add unit test after you agree with the change. Thanks.

Comment 8

[Cody Roesch [:croesch]]

This bug repro's on: Flame 2.1 Master, Flame 2.0, Flame 1.4, Flame v122, Flame v121-2, OpenC 2.1 Master, OpenC 2.0, OpenC 1.4, Buri 2.1 Master, Buri 2.0, Buri 1.4

Actual Results: Bluetooth pairing overlay appears over lock screen.


Environmental Variables:
Device: Flame Master
Build ID: 20140623053744
Gaia: bd5065ced020014df5fd45259fba1ac32d65673b
Gecko: 335b6610fe0c
Version: 33.0a1 (Master)
Firmware Version: v122
--------------------------------------------------
Environmental Variables:
Device: Flame 2.0
Build ID: 20140623051745
Gaia: 84ca0fe0a86d039f6d99cb562f52ef55045dee1d
Gecko: cef223bae66b
Version: 32.0a2 (2.0)
Firmware Version: v122
--------------------------------------------------
Environmental Variables:
Device: Flame 1.4
Build ID: 20140623000201
Gaia: 3419a1f68aaf64a0688685bce42d4173b6125597
Gecko: 34ecc9af3560
Version: 30.0 (1.4)
Firmware Version: v122
--------------------------------------------------
Environmental Variables:
Device: Flame 1.3
Build ID: 20140616171114
Gaia: e1b7152715072d27e0880cdc6b637f82fa42bf4e
Gecko: e181a36ebafaa24e5390db9f597313406edfc794
Version: 28.0 (1.3)
Firmware Version: v122
--------------------------------------------------
Environmental Variables:
Device: Flame 1.3
Build ID: 20140610200025
Gaia: e106a3f4a14eb8d4e10348efac7ae6dea2c24657
Gecko: b637b0677e15318dcce703f0358b397e09b018af
Version: 28.0 (1.3)
Firmware Version: v121-2
--------------------------------------------------
Environmental Variables:
Device: Open_C Master
Build ID: 20140623185652
Gaia: 45479c07cb6ba8c733093d6ee32c767c090c9a28
Gecko: e86b84998b18
Version: 33.0a1 (Master)
Firmware Version: P821A10V1.0.0B06_LOG_DL
--------------------------------------------------
Environmental Variables:
Device: Open_C 2.0
Build ID: 20140623173149
Gaia: 9d2f7bd16a8dc0c74c97c5a40d2f0731f3dfff4b
Gecko: f118b45daada
Version: 32.0a2 (2.0)
Firmware Version: P821A10V1.0.0B06_LOG_DL
--------------------------------------------------
Environmental Variables:
Device: Open_C 1.4
Build ID: 20140623000201
Gaia: 3419a1f68aaf64a0688685bce42d4173b6125597
Gecko: 34ecc9af3560
Version: 30.0 (1.4)
Firmware Version: P821A10V1.0.0B06_LOG_DL
--------------------------------------------------
Environmental Variables:
Device: Buri Master
Build ID: 20140623185652
Gaia: 45479c07cb6ba8c733093d6ee32c767c090c9a28
Gecko: e86b84998b18
Version: 33.0a1 (Master)
Firmware Version: v1.2device.cfg
--------------------------------------------------
Environmental Variables:
Device: Buri 2.0
Build ID: 20140623173149
Gaia: 9d2f7bd16a8dc0c74c97c5a40d2f0731f3dfff4b
Gecko: f118b45daada
Version: 32.0a2 (2.0)
Firmware Version: v1.2device.cfg
-------------------------------------------------
Environmental Variables:
Device: Buri 1.4
Build ID: 20140623175951
Gaia: 1d52323cd5b6c7d646f444712c81777d34f74e36
Gecko: 4e9d3d4412f9
Version: 30.0 (1.4)
Firmware Version: v1.2device.cfg

Comment 9

[Joshua Mitchell (Inactive)]

Issue is not a regression as it is present in every branch.

Comment 10

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

I would like to say it's not a blocking issue. It should be a security issue. Because a user is able to pair with other device without unlock the screen.

Comment 11

[howie [:howie]]

Based on Comment 9 and Comment 10, remove blocking.

Comment 12

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

Comment on attachment 8444932 [details] [review]
pull request 20915

IMHO Introducing a flag for this scenario makes the code hard to trace for me. I left a few comments in github. The ideas was to keep `pairingInfo` during the entire pairing process, so that we can check the existence of it to see if we are in the middle of the pairing process without introducing a new flag. This also saves us from adding code maintaining the flag.

Comment 13

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

Agree with your suggestion before. But we cannot clear up `this.currentPairing` while we have resumed the pairing process. A user might lock the screen --> unlock the screen --> lock the screen --> unlock the screen. But we only have one flag/restored data to manage pairing cycle. I'm wondering how we handle the pairing cycle if we cannot clean up the restored date. Seem like some dependance in one variable `this.currentPairing`. Any suggestion for the dependance?

Comment 14

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

I think if we could always maintain the current pairing info, we could simply show/hide pair view when the screen becomes unlocked/locked.

Comment 15

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

We cannot simply show/hide pair view. Because the pair view is implemented via attention screen. We have to do window.close if expect to hide it. I have tried to set the view hidden. Seem like the container of attention screen is still hover the locked screen.

Comment 16

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

Leave status ASSIGNED. And will go back here if I'm available.

Comment 17

[BMO Automation]

Firefox OS is not being worked on