Closed Bug 1027438 Opened 7 years ago Closed 7 years ago
Screen][System] Change the old locking events with new window events > remove something missing and fork the event
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.
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
Attachment #8442574 - Flags: review?(alive) → review+
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
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.
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 :(
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?
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.
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.
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.
Status: REOPENED → RESOLVED
Closed: 7 years ago → 7 years ago
Resolution: --- → FIXED
I guess we will have a regression here https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/sim_lock.js#L103
You need to log in before you can comment on or make changes to this bug.