Closed Bug 1099006 Opened 10 years ago Closed 10 years ago

[Flame][Lock Screen]The keybord of PIN input page will be displayed on lockscreen after restart device.

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.1+, b2g-v2.0 unaffected, b2g-v2.1 verified, b2g-v2.2 unaffected)

VERIFIED FIXED
2.2 S2 (19dec)
blocking-b2g 2.1+
Tracking Status
b2g-v2.0 --- unaffected
b2g-v2.1 --- verified
b2g-v2.2 --- unaffected

People

(Reporter: huayu.li, Assigned: gweng)

References

Details

(Keywords: regression)

Attachments

(4 files)

Attached video 2.MP4
[1.Description]: [Flame][v2.1][Lock Screen]The keyboard of PIN input page will be displayed on lockscreen after restart device. occurence time: 22:48 see attachments:logcat1.txt,2.mp4.2.png [2.Testing Steps]: 1.Set a PIN of SIM. 2.Set lockscreen. 3.Restart device. [3.Expected Result]: 3.Full locksceen should be displayed. [4.Actual Result]: 3.The keyboard will be displayed in lockscreen. [5.Reproduction build]: Flame 2.1 versions: Gaia-Rev 569a299ca446f714cd98d5881cc058fd6f6e257b Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/d188e92aa5a6 Build-ID 20141113001200 Version 34.0 [6.Reproduction Frequency]: Seldom Recurrence,3/20
Attached image 2.png
Attached file logcat1.txt
Note: Not sure if this issue belongs here or in Gaia::System::Input Mgmt. :gmarty and I saw that regression on our dogfooding devices on each reboot since a couple of days. I rebooted a freshly flashed device, unlocked it, unlocked the SIM and rebooted => I repro'd 5/5 times. [Blocking Requested - why for this release]: Regression which affects all the users with a PIN on their SIM on every reboot.
blocking-b2g: --- → 2.1?
Whiteboard: [systemsfe]
Moving to Sys platform team for triage
Flags: needinfo?(timdream)
Flags: needinfo?(hochang)
Whiteboard: [systemsfe]
This issue only occurs in recent b2g34 2.1 Flame builds but not earlier builds from the same branch or any other branches so I'll be doing a regression window within the b2g34 branch. Environmental Variables: Device: Flame 2.1 BuildID: 20141117201226 Gaia: 1b231b87aad384842dfc79614b2a9ca68a4b4ff3 Gecko: 95fbd7635152 Gonk: Could not pull gonk. Did you shallow Flash? Version: 34.0 (2.1) Firmware Version: v188-1 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Issue does NOT occur Environmental Variables: Device: Flame 2.2 BuildID: 20141118035525 Gaia: 4aee256937afe9db2520752650685ba61ce6097d Gecko: 7913c9392c5f Gonk: Could not pull gonk. Did you shallow Flash? Version: 36.0a1 (2.2) Firmware Version: v188-1 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0 Environmental Variables: Device: Flame 2.1 BuildID: 20141008073108 Gaia: 7ef2e1e59637a34ca4489c329b3bdee93df3ac6c Gecko: e3d495eb85c6 Gonk: Could not pull gonk. Did you shallow Flash? Version: 34.0a2 (2.1) Firmware Version: v188-1 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Environmental Variables: Device: Flame 2.0 BuildID: 20141118044626 Gaia: 1ede2666f1e6c1b3fd3b282011caf0cbc59544b0 Gecko: bde95439014c Gonk: Could not pull gonk. Did you shallow Flash? Version: 32.0 (2.0) Firmware Version: v188-1 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
QA Contact: jmercado
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Bug 1089529 seems to have caused this issue. Central Regression Window: Last Working Environmental Variables: Device: Flame 2.1 BuildID: 20141112174547 Gaia: 2866e1de1bcf07ae729fb1a8246fb89568bace6a Gecko: bf5c6a85f3e9 Gonk: Could not pull gonk. Did you shallow Flash? Version: 34.0 (2.1) Firmware Version: v188-1 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 First Broken Environmental Variables: Device: Flame 2.1 BuildID: 20141112232645 Gaia: 569a299ca446f714cd98d5881cc058fd6f6e257b Gecko: d188e92aa5a6 Gonk: Could not pull gonk. Did you shallow Flash? Version: 34.0 (2.1) Firmware Version: v188-1 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Last Working gaia / First Broken gecko - Issue does NOT occur Gaia: 2866e1de1bcf07ae729fb1a8246fb89568bace6a Gecko: d188e92aa5a6 First Broken gaia / Last Working gecko - Issue does NOT occur Gaia: 569a299ca446f714cd98d5881cc058fd6f6e257b Gecko: bf5c6a85f3e9 Gaia Pushlog: https://github.com/mozilla-b2g/gaia/compare/2866e1de1bcf07ae729fb1a8246fb89568bace6a...569a299ca446f714cd98d5881cc058fd6f6e257b
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Broken by patch for Bug 1089529 - can you take a look Greg?
Blocks: 1089529
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell) → needinfo?(gweng)
QA Contact: jmercado
Alive: does this means my logic to handle 'system-resize' is wrong here? https://github.com/mozilla-b2g/gaia/pull/25982/files#diff-a97c5f79c7db2097a02a4dd5af48e806R132 Should I solve this by checking some more conditions?
Flags: needinfo?(gweng) → needinfo?(alive)
(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #9) > Alive: does this means my logic to handle 'system-resize' is wrong here? > > https://github.com/mozilla-b2g/gaia/pull/25982/files#diff- > a97c5f79c7db2097a02a4dd5af48e806R132 > > Should I solve this by checking some more conditions? This bug should not happen to v2.2 because sim pin dialog will not ask for focus when it is not the top most UI. For v2.1 I think maybe we could try to check window.layoutManager.keyboardEnabled when getting system-resize event. BTW you should stop immediate propagation if you had resized yourself.
Flags: needinfo?(alive)
Assignee: nobody → gweng
Attached file Patch
Alive: I've tested this fixed the bug. Please take a look if I patched it according your suggestion correctly.
Attachment #8525071 - Flags: review?(alive)
Comment on attachment 8525071 [details] [review] Patch r=me
Attachment #8525071 - Flags: review?(alive) → review+
blocking as a regression, renom if disagree.
blocking-b2g: 2.1? → 2.1+
Flags: needinfo?(hochang)
Gaia-Try is very unhappy but not because of my patch: With my patch: https://treeherder.mozilla.org/ui/#/jobs?repo=gaia-try&revision=f2b5de85aa8b Without my patch: https://treeherder.mozilla.org/ui/#/jobs?repo=gaia-try&revision=444021a36de7 I would test it again, and to see if rebasing would eliminate it.
Looks like it is being handled already, thanks.
Flags: needinfo?(timdream)
I've rebased the patch and now I'm waiting the CI result.
From another PR, it shows the v2.1 Gaia-Try now is burning: https://treeherder.mozilla.org/ui/#/jobs?repo=gaia-try&revision=e492eef041d3 This is my PR: https://treeherder.mozilla.org/ui/#/jobs?repo=gaia-try&revision=1cad03fdd629 You can see the errors (the Gu and Gij) are the same. And I believe the error is irrelevant, since these two PR modified definitely different files. So I submit approval now.
Comment on attachment 8525071 [details] [review] Patch [Approval Request Comment] [Bug caused by] (feature/regressing bug #): The v2.1 code doesn't handle resize event properly, which is caused by 1089529. [User impact] if declined: Error occurs [Testing completed]: Gij burning among others and my patch. You can see my patch didn't add new failures as the above comment shows. However, I think v2.1 CI is going very bad, there is even one linter (calls_handler.js) error in another file, which definitely shows someone land the code care no CI results. [Risk to taking this patch] (and alternatives if risky): CI result may be false negative since now v2.1 is burning. But I don't see any relevant errors. [String changes made]: No
Attachment #8525071 - Flags: approval-gaia-v2.1?(fabrice)
(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #19) > Comment on attachment 8525071 [details] [review] > Patch > > [Approval Request Comment] > [Bug caused by] (feature/regressing bug #): The v2.1 code doesn't handle > resize event properly, which is caused by 1089529. > [User impact] if declined: Error occurs > [Testing completed]: Gij burning among others and my patch. You can see my > patch didn't add new failures as the above comment shows. However, I think > v2.1 CI is going very bad, there is even one linter (calls_handler.js) error > in another file, which definitely shows someone land the code care no CI > results. > [Risk to taking this patch] (and alternatives if risky): CI result may be > false negative since now v2.1 is burning. But I don't see any relevant > errors. > [String changes made]: No Approving now as the current v2.1 tip is in a better shape.
Attachment #8525071 - Flags: approval-gaia-v2.1?(fabrice) → approval-gaia-v2.1+
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.2 S2 (19dec)
This issue has been successfully verified on recent Flame 2.1 Reproducing rate: 0/5 Last Flame 2.1 build: Gaia-Rev 38e17b0219cbc50a4ad6f51101898f89e513a552 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/8b92c4b8f59a Build-ID 20141205001201 Version 34.0
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: