Closed Bug 1163169 Opened 5 years ago Closed 5 years ago

[Lockscreen][Task Manager] Long pressing the home button during the firefox logo and bluescreen on device start will show Task Manager overlay on lockscreen

Categories

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:2.2+, b2g-v2.1 unaffected, b2g-v2.2 verified, b2g-master verified)

VERIFIED FIXED
2.2 S13 (29may)
blocking-b2g 2.2+
Tracking Status
b2g-v2.1 --- unaffected
b2g-v2.2 --- verified
b2g-master --- verified

People

(Reporter: dharris, Assigned: apastor)

References

()

Details

(Keywords: regression, Whiteboard: [3.0-Daily-Testing][systemsfe])

Attachments

(4 files)

Description:
Long pressing the home button during the firefox logo and blue screen on device power up will show Task Manager overlay on lockscreen

Repro Steps:
1) Update a Flame to 20150508010203
2) Restart device
3) During Blue friefox loading screen long press the home button


Actual:
The Task Manager Message appears over the lockscreen rendering the device unusable until restart. The messege reads "Your recent app windows show up here" 


Expected:
The user is brought to the lockscreen without the task manager overlay

Environmental Variables:
Device: Flame 3.0 (319mb)(Kitkat)(Full Flash)
Build ID: 20150508010203
Gaia: bc5bfa18f795919b56b952bbf3637c235d0e13dc
Gecko: 356e735fa908
Gonk: a9f3f8fb8b0844724de32426b7bcc4e6dc4fa2ed
Version: 40.0a1 (Master)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0


Repro frequency: 10/10
See attached: Logcat, Video - https://youtu.be/I2w28G7Be3s
This issue DOES occur on Flame 2.2

The Task Manager Message appears over the lockscreen rendering the device unusable until restart. The messege reads "Your recent app windows show up here" 

Environmental Variables:
Device: Flame 2.2 (319mb)(Kitkat)(Full Flash)
Build ID: 20150508002501
Gaia: 88d3ac2721a5484495c2ed60e4a068945f0de5aa
Gecko: 8ad16ebe659d
Gonk: ab265fb203390c70b8f2a054f38cf4b2f2dad70a
Version: 37.0 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

======================================================================================================

This issue does NOT occur on Flame 2.1

The user is brought to the lockscreen without the task manager overlay

Environmental Variables:
Device: Flame 2.1
Build ID: 20150508001200
Gaia: 3e7bd686ecd852f4dfa4605b45f558e6bd34f02a
Gecko: d85173eb5bf4
Gonk: ab265fb203390c70b8f2a054f38cf4b2f2dad70a
Version: 34.0 (2.1)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
[Blocking Requested - why for this release]:
Functional regression.

Requesting a window.
blocking-b2g: --- → 3.0?
Flags: needinfo?(pbylenga)
QA Contact: pcheng
b2g-inbound regression window:

Last Working
Device: Flame
BuildID: 20141219072247
Gaia: 85c5d7d5f7cbf5d3261197d571a0e2215b51d4ee
Gecko: cb54f0d3ab57
Version: 37.0a1 (2.2 Master) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

First Broken
Device: Flame
BuildID: 20141219073743
Gaia: 994125f21ffc162e8fe02b3670380495b5390774
Gecko: 275343e4cd60
Version: 37.0a1 (2.2 Master) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Last Working Gaia First Broken Gecko - no repro
Gaia: 85c5d7d5f7cbf5d3261197d571a0e2215b51d4ee
Gecko: 275343e4cd60

Last Working Gecko First Broken Gaia - repro
Gaia: 994125f21ffc162e8fe02b3670380495b5390774
Gecko: cb54f0d3ab57

Gaia pushlog:
https://github.com/mozilla-b2g/gaia/compare/85c5d7d5f7cbf5d3261197d571a0e2215b51d4ee...994125f21ffc162e8fe02b3670380495b5390774

Caused by bug 1111871.
Blocks: 1111871
Flags: needinfo?(ktucker)
Etienne, can you take a look at this please? Looks like the work done for bug 1111871 is the culprit in this case.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker) → needinfo?(etienne)
Regression. Requires restart to recover.
blocking-b2g: 3.0? → 2.2+
Component: Gaia::System::Lockscreen → Gaia::System::Window Mgmt
Triage 2.2+

Greg, could you please have a look and follow up accordingly? thanks!
Flags: needinfo?(gweng)
Assignee: nobody → apastor
Booting & super early manipulation; not just LockScreen issue. Alive, could you give some advice at current bootstrapping logic?
Flags: needinfo?(gweng) → needinfo?(alive)
Hmm. A simple fix is to block home & holdhome event in logo handler just like this:
https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/ftu_launcher.js#L105

Alberto, lemme know if you have any question to do that.
Flags: needinfo?(alive)
Comment on attachment 8608046 [details] [review]
[gaia] albertopq:1163169-taskmanager-logo > mozilla-b2g:master

Here the patch, but I was wondering if we should find a more generic way (for 3.0). Could we wait for the phone being unlocked (or the homescreen ready) for starting such things like the task manager? We will probably save some startup time.

Thanks!
Attachment #8608046 - Flags: review?(alive)
Comment on attachment 8608046 [details] [review]
[gaia] albertopq:1163169-taskmanager-logo > mozilla-b2g:master

We should not directly use event stopping propagation here (Even we know logo handler would be the very first module to use the event). Read this bug for more detail:
https://bugzilla.mozilla.org/show_bug.cgi?id=1079748

And

https://github.com/mozilla-b2g/gaia/blame/master/apps/system/js/hierarchy_manager.js#L195

Briefly speaking, in order not to create a fixed chain to listen to certain event like home or holdhome to prevent another module to catch events, hierarchy manager was designed to dispatch these events by the given priority of the modules. With this we don't need to care about the starting order of the modules but still have the ability to control the event dispatching order.

So what we need here is adding 2 more functions in InitLogoHandler;
1. respondToHieraryEvent
2. _handle_home & _handle_holdhome
Note: We need to make sure InitLogoHandler is active before returning false in the handlers; otherwise we will always block the event.

What you suggested is good, and it's something I already did in bug 1094759. By design, the side module 'TaskManager' will not be loaded and started (and register holdhome) until the first app (ftu or home) is loaded.
Attachment #8608046 - Flags: review?(alive)
Comment on attachment 8608046 [details] [review]
[gaia] albertopq:1163169-taskmanager-logo > mozilla-b2g:master

Got it! Thanks!
Attachment #8608046 - Flags: review?(alive)
Flags: needinfo?(etienne)
Comment on attachment 8608046 [details] [review]
[gaia] albertopq:1163169-taskmanager-logo > mozilla-b2g:master

Good, r=me, thanks!
Attachment #8608046 - Flags: review?(alive) → review+
Keywords: checkin-needed
http://docs.taskcluster.net/tools/task-graph-inspector/#VvpcvSWEQH-EEAyiRblNWQ

The pull request failed to pass integration tests. It could not be landed, please try again.
Keywords: checkin-needed
https://github.com/mozilla-b2g/gaia/pull/30155

Autolander could not land the pull request due to not having collaborator rights. This is possibly due to a tree closure. Please check the tree status and request checkin again once the tree is open.
Keywords: checkin-needed
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Comment on attachment 8608046 [details] [review]
[gaia] albertopq:1163169-taskmanager-logo > mozilla-b2g:master

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): -
[User impact] if declined: If the user long-presses the home button during booting, will get stuck on the lockscreen with the task manager open. The only option is to restart.
[Testing completed]: Added unit tests.
[Risk to taking this patch] (and alternatives if risky): Blocking home and holdhome buttons until the lockscreen is ready. Added tests, so low risk.
[String changes made]: -
Attachment #8608046 - Flags: approval-gaia-v2.2?
Comment on attachment 8608046 [details] [review]
[gaia] albertopq:1163169-taskmanager-logo > mozilla-b2g:master

APproving and requesting QA verify me on master and 2.2 after patch landed.
Attachment #8608046 - Flags: approval-gaia-v2.2? → approval-gaia-v2.2+
This patch has not yet landed on 2.2 but is in the current 3.0 Nightly Flame build and the issue is NOT fixed.

Actual Results: The user can bring up the task manager by following the steps in the bug description and prevent phone use.

Environmental Variables:
Device: Flame 3.0
BuildID: 20150526010203
Gaia: 7cd4130d4f988562a77d126860408ada65bb95ef
Gecko: 43f2f0c506ea
Gonk: 040bb1e9ac8a5b6dd756fdd696aa37a8868b5c67
Version: 41.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?][failed-verification]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?][failed-verification] → [QAnalyst-Triage+][failed-verification]
Flags: needinfo?(ktucker)
Attached video verified_v2.2.mp4
This bug has been verified as pass on latest Nightly build of Flame v2.2 by the STR in Comment 0.

Actual results: User is brought to the lockscreen without the task manager overlay.
See attachment: verified_v2.2.mp4
Reproduce rate: 0/5

Device: Flame v2.2 build(Pass)
Build ID               20150527002504
Gaia Revision          8084264c4d1e28bc33220bc7443c7425bb76dbcc
Gaia Date              2015-05-27 03:47:15
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/19fcc06fb7ab
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150527.040521
Firmware Date          Wed May 27 04:05:32 EDT 2015
Bootloader             L1TC000118D0
Leaving "verifyme" for v3.0 has not been fixed as mentioned in Comment 20.
Keywords: verifyme
QA Whiteboard: [QAnalyst-Triage+][failed-verification] → [QAnalyst-Triage+][failed-verification][MGSEI-Triage+]
This bug has been verified as pass on latest Nightly build of Flame v3.0 by the STR in Comment 0.

Actual results: User is brought to the lockscreen without the task manager overlay.
See attachment: verified_v3.0.mp4
Reproduce rate: 0/10

Device: Flame v3.0 build(Pass)
Build ID               20150609081840
Gaia Revision          ea27c4ed5b6083c9e21d233d4804372ac4d5d353
Gaia Date              2015-06-08 03:06:41
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/e10e2e8d8bf2
Gecko Version          41.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150609.121441
Firmware Date          Tue Jun  9 12:14:52 EDT 2015
Bootloader             L1TC000118D0
Status: RESOLVED → VERIFIED
Keywords: verifyme
See Also: → 1181004
You need to log in before you can comment on or make changes to this bug.