[Flame] Bluetooth Overlays will show before lockscreen

RESOLVED WONTFIX

Status

Firefox OS
Gaia::System::Window Mgmt
RESOLVED WONTFIX
4 years ago
5 months ago

People

(Reporter: nhirata, Unassigned)

Tracking

unspecified
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(b2g18 affected, b2g-v1.1hd affected, b2g-v1.2 affected, b2g-v1.3 affected, b2g-v1.3T affected, b2g-v1.4 affected, b2g-v2.0 affected)

Details

Attachments

(2 attachments)

Created attachment 8442483 [details]
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 )
blocking-b2g: --- → 2.0?
status-b2g-v2.0: --- → affected
qawanted to check 1.4
Keywords: qawanted
Summary: [Flame] Geolocation, Bluetooth Overlays will show before lockscreen → [Flame] Bluetooth Overlays will show before lockscreen
I had this happen with the geolocation overlay for rocketbar as well.  ( first time use of rocketbar )
(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.

Updated

4 years ago
Assignee: nobody → iliu
blocking-b2g: 2.0? → 2.0+
Status: NEW → ASSIGNED
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.
status-b2g18: --- → affected
status-b2g-v1.1hd: --- → affected
status-b2g-v1.2: --- → affected
status-b2g-v1.3: --- → affected
status-b2g-v1.3T: --- → affected
status-b2g-v1.4: --- → affected
Flags: needinfo?(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.
Flags: needinfo?(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.
Created attachment 8444932 [details] [review]
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.
Attachment #8444932 - Flags: review?(arthur.chen)
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
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Contact: croesch
Issue is not a regression as it is present in every branch.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
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

4 years ago
Based on Comment 9 and Comment 10, remove blocking.
blocking-b2g: 2.0+ → ---
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.
Attachment #8444932 - Flags: review?(arthur.chen)
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?
I think if we could always maintain the current pairing info, we could simply show/hide pair view when the screen becomes unlocked/locked.
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.

Updated

4 years ago
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Leave status ASSIGNED. And will go back here if I'm available.
Status: ASSIGNED → NEW
Assignee: iliu → nobody

Comment 17

5 months ago
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 5 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.