Closed Bug 1216870 Opened 9 years ago Closed 9 years ago

[System][Freeze]App UI frozen after a series of operation on TP

Categories

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

ARM
Gonk (Firefox OS)
defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1208695

People

(Reporter: binjian.tu.hz, Unassigned, Mentored)

References

Details

Attachments

(4 files)

Attached file Pictures.tar.gz
Description:
The screen is frozen at FM radio(can be Messages App or any other app) during following operations(See Reproduce method). Touch & tap any point in FM radio, no response.
1. Press or long touch home key, cannot return to homescreen but vibration still responses.
2. Press volume up & down, it works as expectation.
3. Press Power key, the screen can be lighted on & off.
4. Long press power key, sleep menu is showed as expectation, all the options can be chosen and no frozen on that menu.
5. utility-tray can be dragged down and no frozen
6. Lockscreen works as expectation.

Reproduce method:
1. touch & tap(two fingers) on TP more than 1000 times.
2. launch any App more than 100 times with high frequency.
3. light on / off the screen more than 100 times.
4. Dial & answer calls more than 30 times.

Probability:
2 out of 8 MS during 3 hours test.

Analysis:
See the attachment(issue MS is frozen at Messages App).
issue.jpg is the snapshot of children window list under id="windows" node in system app in issue MS.
ok.jpg is the snapshot of children window list under id="windows" node in system app in MS without the issue.

We doubt some logical defect causes the wrong state in id="homescree" node.
It is impossible that both FM Radio and homescreen are activated at the same time under this circumstance.

And still, you can get the mtklog from:
http://pan.baidu.com/s/1gdKzjm7
Status: NEW → ASSIGNED
Note: 

1. this is a bug following https://bugzilla.mozilla.org/show_bug.cgi?id=1208695, but after some internal discussion this seems to be a different scenario/symptom. 

2. I'm looking for a proper resource from TPE side to help check the log.
See Also: → 1208695
Also put the log mentioned in last line of comment#0

http://pan.baidu.com/s/1gdKzjm7

to GoogleDrive as link below

https://drive.google.com/open?id=0Bz6aW3cbHgB8Y3RQV1VsVW4xbDg
Hi Etienne:

Nice to meet you, it's FxOS TAM Wesly from Mozilla Taipei!

Our partner TCL has reported this 1216870, found during investigation of Bug 1208695 (per information that one caused device shipment on-hold and customer return, they are hoping this 1216870 may give some clue about 1208695 in the end). For this one, is it possible for you to take a look at the log, and let us know if something abnormal you can see, which may related to the symptom described in comment#0?

Or you think there is other one more proper to assist here?

Thanks in advance!
Flags: needinfo?(etienne)
There're two "active" apps when this issue occurs, both transition-state="opened". I suppose somehow a "transitionend" or "animationend" event failed to dispatch to app manager in system app.
Hi Alberto:

Nice to meet you, too! Do you think it's possible for you to take some look at the attached log in comment#2, and let us know if something abnormal you observe, which may related to the symptom described in comment#0? 

Thanks!
Flags: needinfo?(apastor)
I don't see anything from gaia-land in the logs so I don't think Alberto or myself will be able to help.

Comment 4 looks interesting, do we have STRs to reproduce this on a public branch?
Flags: needinfo?(etienne)
Flags: needinfo?(apastor)
Turn on/off "Settings-> Lockscreen" quickly and press power key to enter sleep, wakeup the device again, there are chances when Lock Screen shows but the settings value is off. 

Swipe Lock Screen to unlock, as the judgement at 
https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/lock_screen_window_manager.js#L295, lockscreen will not successfully close, just moved out. Lockscreen and Settings will both show as active, then device fail to respone to touch events.  -  an issue about status sync, not a transition problem.

I fail to reproduce as reported when two apps(lockscreen excluded) are "active".
(In reply to Jin Zhang(T2M) from comment #7)
> Turn on/off "Settings-> Lockscreen" quickly and press power key to enter
> sleep, wakeup the device again, there are chances when Lock Screen shows but
> the settings value is off. 
> 
> Swipe Lock Screen to unlock, as the judgement at 
> https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/
> lock_screen_window_manager.js#L295, lockscreen will not successfully close,
> just moved out. Lockscreen and Settings will both show as active, then
> device fail to respone to touch events.  -  an issue about status sync, not
> a transition problem.

Yep looks like a potential race in the LockscreenWindowManager. Good thing is, it's reproducible on master
Component: Gaia::System → Gaia::System::Lockscreen
Opened Logs in app_window.js and app_window_manager.js. Switch between Message/Contacts/Homescreen, and finally end at a state that Contacts and Homescreen are both 'active', Contacts covers above Homescreen and will not disappear when press home key.
screenshot of webIDE for comment#9
Hi Etienne,

Would you please help check log in comment#9? Can we add some protection when this race condition happens? Seems like when go Contacts back to Homescreen, Messages haven't done closing, then Contacts will not properly be closed.

Some important clues:

[AppWindowManager][3599.261]=== Active app now is: ,Contacts,===
[AppWindowManager][3599.372]=== Active app now is: ,Messages,===
[AppWindowManager][3599.546]=== Active app now is: ,Homescreen,===
[AppWindowManager][3599.768]=== Active app now is: ,Contacts,===
[AppWindowManager][3600.382]=== Active app now is: ,Homescreen,===
[Dump: AppWindow][Messages][AppWindow_19][3600.410]close with reduce
[Dump: AppWindow][Contacts][AppWindow_20][3608.153] Handling mozbrowserasyncscroll event...

stay at Contacts from now on ..
Flags: needinfo?(etienne)
another log, device freeze at Message.

I/GeckoDump(  166): [AppWindowManager][628.842]launchingapp://sms.gaiamobile.org
I/GeckoDump(  166): [AppWindowManager][628.845] current is app://homescreen.gaiamobile.org/index.html#root; next is app://sms.gaiamobile.org/index.html
I/GeckoDump(  166): [Dump: AppWindow][Messages][AppWindow_1][628.846]request RESIZE...active? ,false
I/GeckoDump(  166): [AppWindowManager][628.846]=== Active app now is: ,Messages,===

...

I/GeckoDump(  166): [AppWindowManager][628.962]handling launchapp
I/GeckoDump(  166): [AppWindowManager][628.963]launchingapp://communications.gaiamobile.org/contacts/index.html
I/GeckoDump(  166): [AppWindowManager][628.966] current is app://sms.gaiamobile.org/index.html; next is app://communications.gaiamobile.org/contacts/index.html
Thanks Etienne for the help! As this can be seen on master, too. Do you think you'll be able to help?


Do you think it's the same one as Bug 1208695(In reply to Etienne Segonzac (:etienne) AFK on October 21 and 26 from comment #8)
> (In reply to Jin Zhang(T2M) from comment #7)
> > Turn on/off "Settings-> Lockscreen" quickly and press power key to enter
> > sleep, wakeup the device again, there are chances when Lock Screen shows but
> > the settings value is off. 
> > 
> > Swipe Lock Screen to unlock, as the judgement at 
> > https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/
> > lock_screen_window_manager.js#L295, lockscreen will not successfully close,
> > just moved out. Lockscreen and Settings will both show as active, then
> > device fail to respone to touch events.  -  an issue about status sync, not
> > a transition problem.
> 
> Yep looks like a potential race in the LockscreenWindowManager. Good thing
> is, it's reproducible on master
Hi, Wesly:

We're afraid they are not the same issue.
The solution that Zhangjin has suggested is our concern at first.
And later we found it's the direct cause of #1208695.
Flags: needinfo?(wehuang)
I'm getting a bit lost between the STR for one issues and the logs for another one.
Let's recap :)

This bug is currently filed in the Lockscreen component because the STRs from the description points to a LockscreenWindowManager race. And I probably wont be the most efficient dev to look it up (Greg probably is :))

If we have a separate STR that don't involve the lockscreen at all (like the latest logs added seem to suggest), please file a separate bug in the Gaia:WindowManager component with Steps To Reproduce. Mixing multiple issues on the same bug is the best way to get none of them fixed!
Flags: needinfo?(etienne)
(Thanks Etienne, agree w/ you.)

Hi Keith:

Started from comment#7, another issue was introduced and in the end the main discussion here is actually for 1216870, so I'll duplicate this one to 1216870. Please help raise a new one as Etienne suggested and have corresponding STR & log, for clarity. Thanks. 

(In reply to Etienne Segonzac (:etienne) AFK on October 21 and 26 from comment #15)
> I'm getting a bit lost between the STR for one issues and the logs for
> another one.
> Let's recap :)
> 
> This bug is currently filed in the Lockscreen component because the STRs
> from the description points to a LockscreenWindowManager race. And I
> probably wont be the most efficient dev to look it up (Greg probably is :))
> 
> If we have a separate STR that don't involve the lockscreen at all (like the
> latest logs added seem to suggest), please file a separate bug in the
> Gaia:WindowManager component with Steps To Reproduce. Mixing multiple issues
> on the same bug is the best way to get none of them fixed!
Flags: needinfo?(wehuang) → needinfo?(binjian.tu.hz)
Sorry I mean 1208695, as mentioned in comment#14.

(In reply to Wesly Huang (TAM) from comment #16)
> (Thanks Etienne, agree w/ you.)
> 
> Hi Keith:
> 
> Started from comment#7, another issue was introduced and in the end the main
> discussion here is actually for 1216870, so I'll duplicate this one to
> 1216870. Please help raise a new one as Etienne suggested and have
> corresponding STR & log, for clarity. Thanks. 
> 
> (In reply to Etienne Segonzac (:etienne) AFK on October 21 and 26 from
> comment #15)
> > I'm getting a bit lost between the STR for one issues and the logs for
> > another one.
> > Let's recap :)
> > 
> > This bug is currently filed in the Lockscreen component because the STRs
> > from the description points to a LockscreenWindowManager race. And I
> > probably wont be the most efficient dev to look it up (Greg probably is :))
> > 
> > If we have a separate STR that don't involve the lockscreen at all (like the
> > latest logs added seem to suggest), please file a separate bug in the
> > Gaia:WindowManager component with Steps To Reproduce. Mixing multiple issues
> > on the same bug is the best way to get none of them fixed!
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
(In reply to Wesly Huang (TAM) from comment #18)
> 
> *** This bug has been marked as a duplicate of bug 1208695 ***

Only comment 7 mentioned a little bit information from #1208695.
All the logs zhangjin'd provided is exactly what the title issue highlighted, not #1208695.
Please don't mistake this issue as #1208695.
Although I create a new bug, I will still use the same description and log file attachment, which only wastes of our time. Do you think so?
Just ignore the comment#7 & #8 here. Then all clean.
Therefore, the title issue hasn't been resolved.
Flags: needinfo?(binjian.tu.hz) → needinfo?(wehuang)
Sorry Keith but after reading through all comments again I still agree w/ Etienne that keep using this bug w/ mixed issues will be the best way to get none of them fixed. It's already not easy to get resource at this moment so a clear and concise bugzilla description/summary will be helpful to increase its chance to be processed&fixed. I would suggest to combine & summarize necessary information in a new bug. 

Thanks for the understanding.

(In reply to Keith Tu from comment #19)
> (In reply to Wesly Huang (TAM) from comment #18)
> > 
> > *** This bug has been marked as a duplicate of bug 1208695 ***
> 
> Only comment 7 mentioned a little bit information from #1208695.
> All the logs zhangjin'd provided is exactly what the title issue
> highlighted, not #1208695.
> Please don't mistake this issue as #1208695.
> Although I create a new bug, I will still use the same description and log
> file attachment, which only wastes of our time. Do you think so?
> Just ignore the comment#7 & #8 here. Then all clean.
> Therefore, the title issue hasn't been resolved.
Flags: needinfo?(wehuang)
Ok, I understand.
I'll fire a new one later.
And could you take a look at the follow one:
https://bugzilla.mozilla.org/show_bug.cgi?id=1218658

It's pretty close to the title one.

log & snapshot & video & comment, all provided.
I think it can be able to help your engineer to analyze.
Flags: needinfo?(wehuang)
thanks Keith, have checked 1218658 and asked help for corresponding module people.
Flags: needinfo?(wehuang)
I've filed another new one:
https://bugzilla.mozilla.org/show_bug.cgi?id=1220028

Please arrange some engineer to analyze it.
Flags: needinfo?(wehuang)
to follow up in https://bugzilla.mozilla.org/show_bug.cgi?id=1220028
Flags: needinfo?(wehuang)
See Also: → 1220028
Assignee: wehuang → nobody
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: