Closed
Bug 1027438
Opened 10 years ago
Closed 10 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)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: gweng, Assigned: gweng)
References
Details
Attachments
(2 files)
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.
Assignee | ||
Updated•10 years ago
|
Blocks: lockscreen-as-app
Assignee | ||
Comment 1•10 years ago
|
||
Waiting CI result. Would set reviewer later.
Assignee | ||
Comment 2•10 years ago
|
||
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.
Assignee | ||
Updated•10 years ago
|
Attachment #8442574 -
Flags: review?(alive)
Assignee | ||
Updated•10 years ago
|
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 | ||
Updated•10 years ago
|
Assignee: nobody → gweng
Updated•10 years ago
|
Attachment #8442574 -
Flags: review?(alive) → review+
Assignee | ||
Comment 3•10 years ago
|
||
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Comment 4•10 years ago
|
||
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 → ---
Assignee | ||
Comment 5•10 years ago
|
||
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)
Assignee | ||
Comment 6•10 years ago
|
||
Another OK path:
make reset-gaia (without DEVICE_DEBUG=1) -> FTU -> HomeScreen -> Settings app -> HomeScreen -> lock -> HomeScreen
Comment 7•10 years ago
|
||
(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)
Assignee | ||
Comment 8•10 years ago
|
||
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)
Assignee | ||
Comment 9•10 years ago
|
||
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.
Assignee | ||
Comment 10•10 years ago
|
||
OK, I'm now estimate how frequently the bug would occur. And hope I can find a quick solution for this race condition.
Assignee | ||
Updated•10 years ago
|
Flags: needinfo?(21)
Assignee | ||
Comment 11•10 years ago
|
||
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.
Assignee | ||
Comment 12•10 years ago
|
||
Fixed the regression. Waiting for tests result.
Assignee | ||
Comment 13•10 years ago
|
||
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.
Assignee | ||
Comment 14•10 years ago
|
||
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.
Assignee | ||
Comment 15•10 years ago
|
||
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → FIXED
Comment 16•10 years ago
|
||
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.
Description
•