Closed Bug 990435 Opened 11 years ago Closed 11 years ago

[tarako] the two homescreens randomly overlapped with each other after wake up from sleep

Categories

(Firefox OS Graveyard :: Gaia::Homescreen, defect)

Other
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:1.3T+, b2g-v1.3T fixed, b2g-v1.4 affected, b2g-v2.0 fixed)

RESOLVED FIXED
2.0 S1 (9may)
blocking-b2g 1.3T+
Tracking Status
b2g-v1.3T --- fixed
b2g-v1.4 --- affected
b2g-v2.0 --- fixed

People

(Reporter: angelc04, Assigned: gduan)

References

Details

Attachments

(5 files)

Attached image screenshot_154828.jpg (deleted) —
STR: 1. put device to sleep for a long time (over 10 minutes) 2. Wake device up and unlock screen --> We randomly see the two homescreens overlapped. (please see attached screenshot.) The reproduce rate is very low. But we keep seeing this problem in recent build for about twice per day.
Attached file Adb logcat (deleted) —
Attached adb log when problem occurs.
From the second picture croped from the nightly,you could see the translateX of the two pages are the same,so they overlapped with each other. In a normal phone,the two pages should have a difference of 320px in Tarako.
hi,Alive Do you know where may cause the value of translateX computed wrong?Thank you.
Flags: needinfo?(alive)
We reproduced twice again just now. -> The first time is to delete some files from Sd card when device was sleeping. Then when we unlock it we saw the homescreen overlapped. -> The second time is to recieve email notification when device was asleep. Then when we wake it up, we saw this problem.
blocking-b2g: --- → 1.3T?
Cristian, any pointers that could help here?
Flags: needinfo?(crdlc)
is there any stable STR? thanks
Flags: needinfo?(pcheng)
(In reply to Joe Cheng [:jcheng] from comment #7) > is there any stable STR? thanks No,we haven't found the stable STR. Maybe it's something about the transition,I think.Something interrupts the transition when it's on transition may cause this issue,I guess.
Homescreen issue, clearing.
Flags: needinfo?(alive)
(In reply to Joe Cheng [:jcheng] from comment #7) > is there any stable STR? thanks No, we haven't find a stable STR. But this screen only appears after waking up device from sleep. If we leave screen on forever, it will not appear.
Flags: needinfo?(pcheng)
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
oops, I think it should not be the same issue from comment 3, my mistake. Reopened now
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
George was traced the code about the logic of homescreen page transition. He's helping on digging more hint.
Flags: needinfo?(gduan)
TBH I don't have idea but translation should not have being performed during idle thought (In reply to Gregor Wagner [:gwagner] from comment #6) > Cristian, any pointers that could help here?
Flags: needinfo?(crdlc) → needinfo?(21)
I guess it's probably due to window.innerWidth is detected as 0 in grid.js and dock.js, so the icons in dock and pages are not positioned rightly. ps: dock bar should contains 4 icons but it now only show 2 icons.
Flags: needinfo?(gduan)
George, could you reproduce and/or provide a quick patch? Or, if you could provide a patch that adds logs to possible lines and have people to test it out? Thanks.
Assignee: nobody → gduan
Status: REOPENED → ASSIGNED
Flags: needinfo?(gduan)
(In reply to yang.zhao from comment #3) > From the second picture croped from the nightly,you could see the translateX > of the two pages are the same,so they overlapped with each other. In a > normal phone,the two pages should have a difference of 320px in Tarako. This comment is particularly interesting. I think George is right and the issue happens when the homescreen has been killed in the background. I can reproduce the issue with those steps: - Turn off the phone - Kill the homescreen app with |adb shell b2g-ps; find the homescreen pid; adb shell kill homescreen_pid| - Turn on the device and ensure the homescreen has been restarted with |adb shell b2g-ps| - Unlock the screen and see the homescreen is broken The issue is likely that window.innerWidth is 0 until the homescreen has been set to visible from the system app. In https://github.com/mozilla-b2g/gaia/blob/master/apps/homescreen/js/grid.js#L38 we get the size of the window only at application startup and never update it afterward. We likely needs to update the width at some point and force a re-arrangement of the homescreen if it has changed between 2 visibilities state.
Flags: needinfo?(21)
(In reply to pcheng from comment #10) > (In reply to Joe Cheng [:jcheng] from comment #7) > > is there any stable STR? thanks > > No, we haven't find a stable STR. But this screen only appears after waking > up device from sleep. If we leave screen on forever, it will not appear. If the device is on the innerWidth should be correct. When the homescreen is restarted but the screen is off, then the width/height should be 0.
(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #17) > (In reply to yang.zhao from comment #3) > > From the second picture croped from the nightly,you could see the translateX > > of the two pages are the same,so they overlapped with each other. In a > > normal phone,the two pages should have a difference of 320px in Tarako. > > This comment is particularly interesting. > > I think George is right and the issue happens when the homescreen has been > killed in the background. > > I can reproduce the issue with those steps: > - Turn off the phone > - Kill the homescreen app with |adb shell b2g-ps; find the homescreen pid; > adb shell kill homescreen_pid| > - Turn on the device and ensure the homescreen has been restarted with |adb > shell b2g-ps| > - Unlock the screen and see the homescreen is broken > > The issue is likely that window.innerWidth is 0 until the homescreen has > been set to visible from the system app. In > https://github.com/mozilla-b2g/gaia/blob/master/apps/homescreen/js/grid. > js#L38 we get the size of the window only at application startup and never > update it afterward. > > We likely needs to update the width at some point and force a re-arrangement > of the homescreen if it has changed between 2 visibilities state. If fetch window.innerWidth doesn't cause reflow I suggest to renew it while visibilitychange event is caught in homescreen app.
Attached file PR to 1.3t (deleted) —
Based on comment 17 and comment 19, This patch can fix what comment 17 stated, but I'm not sure if there's any side-effect. Hi Chris, could you take a look?
Attachment #8400555 - Flags: review?(crdlc)
Flags: needinfo?(gduan)
Comment on attachment 8400555 [details] PR to 1.3t LGTM. There are two minor suggestions on github 1) Added a comment why we do it in the code 2) Move the listener below the instruction that calculates the width r+! Good job!
Attachment #8400555 - Flags: review?(crdlc) → review+
Attached file PR to master (deleted) —
Sorry, I should merge to master first.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
Please land it on v1.3t. Thanks.
Flags: needinfo?(styang)
Flags: needinfo?(jcheng)
I also see this problem in Buri V1.4 build. Should we also merge this fix to v1.4?
Flags: needinfo?(styang)
add some flags
blocking-b2g: 1.3T? → 1.3T+
Flags: needinfo?(jcheng)
Whiteboard: [1.4-approval-needed]
Please, George, take a look at this bug 991906 comment 3 because I guess that the regression was introduced here. Maybe you should do something like (no real code, just the idea a wrote): width = innerWitdh; if (width === 0) { addEventListeter('visibilitychange') { removeEventListener() inside } }
sorry, I forgot the ni :)
Flags: needinfo?(gduan)
(In reply to George Duan [:gduan] [:喬智] from comment #22) > Created attachment 8400836 [details] > PR to master > > Sorry, I should merge to master first. hi,George We sometimes could reproduce this issue with the patch.Maybe there is something else should be modified.And I haven't found the STR.
(In reply to yang.zhao from comment #30) > (In reply to George Duan [:gduan] [:喬智] from comment #22) > > Created attachment 8400836 [details] > > PR to master > > > > Sorry, I should merge to master first. > > hi,George > We sometimes could reproduce this issue with the patch.Maybe there is > something else should be modified.And I haven't found the STR. File another bug when you can reproduce it continuously. Thanks.
Depends on: 991906
Reply in bug 991906 (In reply to Cristian Rodriguez (:crdlc) from comment #29) > sorry, I forgot the ni :) Hi Yang, Same result as the screenshot, including the icons of dockbar and page are misplaced? What's the last app you launched?
Flags: needinfo?(gduan) → needinfo?(yang.zhao)
This bug is not completely fixed. I still see overlapped homescreen and misplaced icons on dockbar. Good news is: user can tap on Home button or swipe to recover from overlap problem. But misplaced icons on dockbar is not recoverable. We are still trying to figure out a STR. Test build: Gaia 9afe8145b5d309bdf2ef196b559e6dfd997faeeb Gecko https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/c2a0ee7b4d58 BuildID 20140407164002 Version 28.1 ro.build.version.incremental=eng.cltbld.20140407.202457 ro.build.date=Mon Apr 7 20:25:04 EDT 2014
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
pcheng, can you open another bug when you have STR? i prefer we keep this closed unless this causes regression that should be backed up. thanks
Flags: needinfo?(pcheng)
Agree with comment 34 - reclosing the bug here.
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
(In reply to George Duan [:gduan] [:喬智] from comment #32) > Reply in bug 991906 > (In reply to Cristian Rodriguez (:crdlc) from comment #29) > > sorry, I forgot the ni :) > > Hi Yang, > Same result as the screenshot, including the icons of dockbar and page are > misplaced? > What's the last app you launched? Also after running the monkey test,so I don't know the last app launched.I can't remember whether the icons are misplaced,I'll take a screenshot if it reproduces again.
Flags: needinfo?(yang.zhao)
Flags: needinfo?(pcheng)
Please file a new bug, Peipei.
Flags: needinfo?(pcheng)
(In reply to James Zhang from comment #37) > Please file a new bug, Peipei. I cloned this bug to bug 995886
Flags: needinfo?(pcheng)
No longer blocks: 995886
Is this something that's still wanted on 1.4? Seems that way per the whiteboard, but I don't see an approval request here.
Flags: needinfo?(gduan)
Target Milestone: --- → 2.0 S1 (9may)
Based on comment 17, we can reproduced this bug if we force to kill homescreen in the background when screen off on 1.4 branch. Device may kill homescreen app due to OOM, which is relatively often seen on tarako due to its small memory size. I suggest to merge it into v1.4 in case, and also with bug 991906 for another side effect.
Flags: needinfo?(gduan)
Please request approval-gaia-v1.4 on the appropriate PR in that case :)
Flags: needinfo?(gduan)
Please ignore comment 40. After testing bug 990435 and bug 991906 on v1.4, I would suggest not to merge to v1.4 for below reasons. 1. no related blocker for v1.4 2. bug 990435 and bug 991906 don't completely solve comment 17. 3. it might be risky to have these commits in v1.4 (see item 2)
Flags: needinfo?(gduan)
Hi George, This issue happens in v1.4 on Dolphin as well. If the original patch does not fit v1.4 (based on your comment 43). We need your help to create another patch for uplifting the fix to v1.4.
Flags: needinfo?(gduan)
Flags: needinfo?(gduan)
Per comment 45 and https://bugzilla.mozilla.org/show_bug.cgi?id=995886#c66, the fix here is specific to Tarako only and not suitable to be uplifted to v1.4. Partner can check if this one can be reproduced on Flame and nominate a new bug to v1.4 accordingly. Clean the 1.4-approval-needed flag in whiteboard for now.
Whiteboard: [1.4-approval-needed]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: