998121 - Calling window.lockScreen.lock() hides windows and does not show lockscreen

Status: RESOLVED INVALID

(Firefox OS Graveyard :: Gaia::System::Lockscreen, defect)

Description

[Eitan Isaacson [:eeejay]]

Attachment: State of screen after calling lockScreen.lock()

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.

Comment 1

[Eitan Isaacson [:eeejay]]

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

[Greg Weng [:snowmantw][:gweng][:λ]]

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

Comment 3

[Eitan Isaacson [:eeejay]]

(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

[Greg Weng [:snowmantw][:gweng][:λ]]

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.

Comment 5

[Eitan Isaacson [:eeejay]]

(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

[Greg Weng [:snowmantw][:gweng][:λ]]

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.

Comment 7

[Eitan Isaacson [:eeejay]]

After the actual bugs in bug #985037, this will not be an issue.