Closed
Bug 1020917
Opened 11 years ago
Closed 10 years ago
Lock screen no longer blocks home key press
Categories
(Firefox OS Graveyard :: Gaia::System::Lockscreen, defect)
Tracking
(blocking-b2g:2.0+, b2g-v2.0 fixed, b2g-v2.1 verified)
People
(Reporter: timdream, Assigned: gweng)
References
Details
(Keywords: regression)
Attachments
(3 files, 3 obsolete files)
On master with Flame.
STR:
1. launch an app to foreground
2. Press sleep
3. Press sleep again, see lock screen
4. Press home
5. swipe and unlock
Expected:
1. See my foreground app
Actual:
1. See home screen
Note:
Let's find the regression window first to see the affect releases and the offending patch.
Updated•11 years ago
|
QA Contact: ddixon
Updated•11 years ago
|
blocking-b2g: 2.0? → 2.0+
Comment 1•11 years ago
|
||
Issue DOES occur in 1.3 and 1.4 Flame builds.
B2G Inbound Regression Window (Buri device):
Last Working:
Device: Buri
Build ID: 20140403064233
Gaia: 90b62f2030c58e2207b2fa2c5892f8b51e178b52
Gecko: e2e287901e1f
Version: 31.0a1 (Master) MOZ
Firmware Version: v1.2device.cfg
First Broken:
Device: Buri
Build ID: 20140403070634
Gaia: 680f2b0f22dac1eea680158c419a1c7d8a0ad70e
Gecko: d2c0858051bc
Version: 31.0a1 (Master) MOZ
Firmware Version: v1.2device.cfg
Last Working Gecko and First Broken Gaia
Issue DOES occur here.
Gaia: 680f2b0f22dac1eea680158c419a1c7d8a0ad70e
Gecko: e2e287901e1f
Last Working Gaia and First Broken Gecko
Issue DOES NOT occur here.
Gaia: 90b62f2030c58e2207b2fa2c5892f8b51e178b52
Gecko: d2c0858051bc
Gaia Pushlog: https://github.com/mozilla-b2g/gaia/compare/90b62f2030c58e2207b2fa2c5892f8b51e178b52...680f2b0f22dac1eea680158c419a1c7d8a0ad70e
Keywords: regressionwindow-wanted
Updated•11 years ago
|
Blocks: lockscreen-window
Assignee | ||
Comment 2•11 years ago
|
||
I've found this is because the previous assumption -- the lockscreen.js would block the event before AppWindowManager -- now is broken. So I remove it and let the block happen in AppWindowManager to solve this.
Attachment #8436611 -
Flags: review?(alive)
Assignee | ||
Comment 3•11 years ago
|
||
Attachment #8436612 -
Flags: review?(alive)
Comment 4•11 years ago
|
||
Comment on attachment 8436612 [details]
Patch v2.0
I dislike AWM knows detail of lock state(although there might be for now). This makes AWM become an all mighty god module again.
Couldn't we block this event in LWM to swallow the home event and improve it later in homeEventDispatcher?
Comment 5•11 years ago
|
||
Comment on attachment 8436611 [details]
Patch
clear before having conclusion
Attachment #8436611 -
Flags: review?(alive)
Updated•11 years ago
|
Attachment #8436612 -
Flags: review?(alive)
Assignee | ||
Comment 6•11 years ago
|
||
I've tried to block it in LWM. However, it never worked, because (as I watched from log) AWM would receive the event *before* LWM. I've also tried to move the order of the initialization of LWM as the first component at the bootstrap.js, but AWM seems would be initialized even before the bootstrap.js' loading callback, it still not worked. So I can only provide solution like this. If you have any better idea, since you know more about System app & bootstrapping than me, I'm glad to fix the patch.
Another idea to solve this is to make a home button manager (or something like that), which would ask all registered auditors (like LWM) to see if the event can be really handled before it got received by other components. In this way we can centralize the event blocking things with a formal component. But this seems complex and may be not so necessary.
Flags: needinfo?(alive)
Comment 7•11 years ago
|
||
A proper fix is to make AppWindowManager instantiable and put off its start after lwm start.
But that will change a lot of modules/tests.
I am going to provide a simple workaround.
Flags: needinfo?(alive)
Comment 8•11 years ago
|
||
(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #7)
> A proper fix is to make AppWindowManager instantiable and put off its start
> after lwm start.
> But that will change a lot of modules/tests.
> I am going to provide a simple workaround.
Well, my proposal is moving AppWindowManager.init() to bootstrap.js, right after LWM.start();
Could you try this? You are still assignee and this shouldn't touch too many stuff.
Assignee | ||
Comment 9•11 years ago
|
||
Yes, I would take some time to solve this while I'm not on duty (MAE) according to your suggestion. Thank you.
Updated•10 years ago
|
Assignee: nobody → gweng
Updated•10 years ago
|
Target Milestone: --- → 2.0 S5 (4july)
Comment 11•10 years ago
|
||
(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #9)
> Yes, I would take some time to solve this while I'm not on duty (MAE)
> according to your suggestion. Thank you.
Any update? We don't have any updates for a really long time here!
Flags: needinfo?(gweng)
Assignee | ||
Comment 13•10 years ago
|
||
Waiting for tests to set review.
Attachment #8436611 -
Attachment is obsolete: true
Attachment #8436612 -
Attachment is obsolete: true
Assignee | ||
Comment 14•10 years ago
|
||
Comment on attachment 8448526 [details]
Patch
Since TBPL hook now is down, I set the review flag first.
Attachment #8448526 -
Flags: review?(alive)
Comment 15•10 years ago
|
||
Comment on attachment 8448526 [details]
Patch
Please at least have a test in lockscreen_window_manager
Attachment #8448526 -
Flags: review?(alive) → feedback+
Assignee | ||
Comment 16•10 years ago
|
||
^^ Done. Also fixed some errors.
Attachment #8448806 -
Flags: review?(alive)
Assignee | ||
Comment 17•10 years ago
|
||
Patch for 2.0, and obsoleted the old patch which has been deleted.
Attachment #8448526 -
Attachment is obsolete: true
Updated•10 years ago
|
Attachment #8448806 -
Flags: review?(alive) → review+
Assignee | ||
Comment 18•10 years ago
|
||
The failed tests now passed except one GI and GU failure which passed before:
https://tbpl.mozilla.org/?rev=12dec0d1ba57facac4082d4a1e65dc8e951ef300&tree=Gaia-Try
Assignee | ||
Comment 19•10 years ago
|
||
Assignee | ||
Comment 20•10 years ago
|
||
v2.0 patch also passed all tests except one known issue:
https://travis-ci.org/mozilla-b2g/gaia/jobs/29025557
Assignee | ||
Comment 21•10 years ago
|
||
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•10 years ago
|
status-b2g-v2.0:
--- → fixed
Comment 22•10 years ago
|
||
Reverted for Gaia unit test perma-fail on TBPL.
v2.0: https://github.com/mozilla-b2g/gaia/commit/26f82bf95d237272e66955bbca3323ccf8fcb74a
https://tbpl.mozilla.org/php/getParsedLog.php?id=43021020&tree=Mozilla-Aurora
status-b2g-v2.1:
--- → fixed
Assignee | ||
Comment 23•10 years ago
|
||
Fixed the error and let's try it again.
v2.0: https://github.com/mozilla-b2g/gaia/commit/d7d1b769ac5e826ce49b443a36ca283d3f74f239
Assignee | ||
Updated•10 years ago
|
Updated•10 years ago
|
Comment 24•10 years ago
|
||
This issue has been successfully verified on Flame 2.1:
Gaia-Rev 1bdd49770e2cb7a7321e6202c9bf036ab5d8f200
Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/db893274d9a6
Build-ID 20141125001201
Version 34.0
Device-Name flame
FW-Release 4.4.2
You need to log in
before you can comment on or make changes to this bug.
Description
•