Closed Bug 1027438 Opened 7 years ago Closed 7 years ago

[LockScreen][System] Change the old locking events with new window events > remove something missing and fork the event

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: gweng, Assigned: gweng)

References

Details

Attachments

(2 files)

46 bytes, text/x-github-pull-request
alive
: review+
Details | Review
46 bytes, text/x-github-pull-request
Details | Review
I've found that I still missed some listener in System app, so I would fix them in this bug. And, I want to change the event source, so any others still want to listen them would encounter errors. This would prevent people use then again.
Attached file Patch
Waiting CI result. Would set reviewer later.
Travis failed at the specific tests as the other PRs:

https://travis-ci.org/mozilla-b2g/gaia/builds/28745424

However TBPL passed:

https://tbpl.mozilla.org/?tree=Gaia-Try&rev=523b83bd11b0fdc8ed4aa05f848a78c0ba9978b8

So I'll set the review flag.
Attachment #8442574 - Flags: review?(alive)
Summary: [LockScreen][System] Change the old locking events with new window events > remove something missed and fork the event → [LockScreen][System] Change the old locking events with new window events > remove something missing and fork the event
Assignee: nobody → gweng
Attachment #8442574 - Flags: review?(alive) → review+
master: https://github.com/mozilla-b2g/gaia/commit/9887e6ec29482566343b44dc82c017703af1c633
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Sorry I had to backout this patch. It prevent my homescreen to start on the flame with this on the console:

E/GeckoConsole( 2281): [JavaScript Error: "TypeError: window.AppWindowManager.getActiveApp(...) is null" {file: "app://system.gaiamobile.org/js/system.js" line: 16}]

It seems like the homescreen is started, but it not rendered on the screen. If I open the settings app from the utility tray and come back, then the homescreen is rendered.

Backout: https://github.com/mozilla-b2g/gaia/commit/3d93607bb384cbf4fd06779925e32a1e74a073e5
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Vivien: I use my flame without any problem to launch Homescreen with this patch. Can you provide your STR? I've tried these:

1. reset-gaia (without LockScreen) -> bootstrap -> launch Settings app -> back to Homescreen: OK
2. Settings app -> enable LockScreen -> back to Homescreen -> lock the device -> unlock: OK
3. launch Settings app -> lock the device -> unlock -> home key -> back to Homescreen: OK

I choose Settings app just because I need to enable LockScreen via it.
Flags: needinfo?(21)
Another OK path:

make reset-gaia (without DEVICE_DEBUG=1) -> FTU -> HomeScreen -> Settings app -> HomeScreen -> lock -> HomeScreen
(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #6)
> Another OK path:
> 
> make reset-gaia (without DEVICE_DEBUG=1) -> FTU -> HomeScreen -> Settings
> app -> HomeScreen -> lock -> HomeScreen

I see that only when I reboot the b2g process. Then this error pops up. Sounds like a race :(
Flags: needinfo?(21)
I killed the process manually and finally found it. However, I don't know whether we should back out a patch that it's regressions can only be found in such case. If ordinary user can't encounter it in daily use, and it passed all test, can we put it back until some other serious regressions from more use cases?
Flags: needinfo?(21)
Or I can solve the race in another follow-up bug. I even suspect that the race condition can be reproduce without my patch in the manual killing case.
OK, I'm now estimate how frequently the bug would occur. And hope I can find a quick solution for this race condition.
Flags: needinfo?(21)
It seems I found the symptom is caused by the Homescreen window would not be activated after LockScreen fade out. So that even though the app is existing, the iframe still is hidden. However I still need to find the root cause of this.
Attached file Patch v2
Fixed the regression. Waiting for tests result.
It passed all tests on TBPL except the Vertical home issue:

https://tbpl.mozilla.org/?tree=Gaia-Try&rev=cd427435a9dfc13974ac6e5a654abf998225df2e

I'll wait for Travis, which shows the tests failed at some timeout and connection refuse issue.

If they're failed again I'll land this patch according to TBPL's result.
Okay. The failed unit test on Travis is because of a timeout issue at before each stage, and it passed on TBPL:

https://travis-ci.org/mozilla-b2g/gaia/jobs/28833802

And the failed Travis integration test is the wildly known Music progress bar issue:

https://travis-ci.org/mozilla-b2g/gaia/jobs/28833803

So I'll land this patch and to see if everything is fine.
master: https://github.com/mozilla-b2g/gaia/commit/4cf99407c82b5aab3fe5d2e064378fa9d0667e82
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.