Closed
Bug 998121
Opened 11 years ago
Closed 11 years ago
Calling window.lockScreen.lock() hides windows and does not show lockscreen
Categories
(Firefox OS Graveyard :: Gaia::System::Lockscreen, defect)
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: eeejay, Unassigned)
References
Details
Attachments
(1 file)
(deleted),
image/png
|
Details |
I am trying to get a ui test to work, and noticed that when lockScreen.lock() is called via marionette the device gets into an unusable state.
This seems to be because the LockscreenWindowManager does not listen for the 'lock' event to open the lockscreen app.
Reporter | ||
Comment 1•11 years ago
|
||
There is a lot of redundancy in the call/event chain when the screen is locked or unlocked.
1. Both LockScreen and LockScreenWindowManager listen for 'screenchange' to determine if the lockscreen should appear or not.
2. They both check if the screen went off because of proximity.
3. They both check if the FTU is running, and don't lock the screen if it is (LSWM directly, LS in the lockIfEnabled() method).
Comment 2•11 years ago
|
||
Please don't call |lockScreen.lock| directly. It's only for private use and I don't change the name because I have to remain capability before I done the refactoring of these things.
If you want to open the LockScreenWindow with a locked LockScreen, and you're in the System app, you can turn off the screen and turn on it again, or to directly call LockScreenWindowManager#openApp().
The main reason that I've prepare no method to directly control the LockScreen to lock/unlock is in real case it would only response to such user events. If I do it only for test I feel there may be something wrong.
(So I don't think this is a bug that need to be fixed).
Reporter | ||
Comment 3•11 years ago
|
||
(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #2)
> Please don't call |lockScreen.lock| directly. It's only for private use and
> I don't change the name because I have to remain capability before I done
> the refactoring of these things.
>
Sounds good. I encountered this in the gaia-ui tests. Currently, all the lockscreen tests are using lockScreen.lock(), meaning they bring the device to a weird state and everything is not good :)
Comment 4•11 years ago
|
||
I've fixed this once in the atoms used by gaia-ui test. It is at the |gaia_lock_screen.js|, which would use the way I mentioned to open the app.
Reporter | ||
Comment 5•11 years ago
|
||
(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #4)
> I've fixed this once in the atoms used by gaia-ui test. It is at the
> |gaia_lock_screen.js|, which would use the way I mentioned to open the app.
I don't see it here:
https://github.com/mozilla-b2g/gaia/blob/master/tests/atoms/gaia_lock_screen.js#L43
The atom files get copied to tests/python/gaia-ui-tests/gaiatest/atoms/.
You may have modified it there, and forgot to copy it back to where git tracks it?
Comment 6•11 years ago
|
||
It's here:
https://github.com/mozilla-b2g/gaia/blob/master/tests/atoms/gaia_lock_screen.js#L65
I forcibly open the app. Since I have no enough resource to fix the related Gaia UI test completely, I just patched it to make the tests that I saw failed pass.
Reporter | ||
Comment 7•11 years ago
|
||
After the actual bugs in bug #985037, this will not be an issue.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•