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)
Tracking
(blocking-b2g:1.3T+, b2g-v1.3T fixed, b2g-v1.4 affected, b2g-v2.0 fixed)
People
(Reporter: angelc04, Assigned: gduan)
References
Details
Attachments
(5 files)
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.
Reporter | ||
Comment 1•11 years ago
|
||
Reporter | ||
Comment 2•11 years ago
|
||
Attached adb log when problem occurs.
Reporter | ||
Updated•11 years ago
|
status-b2g-v1.3T:
--- → affected
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)
Reporter | ||
Comment 5•11 years ago
|
||
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.
Updated•11 years ago
|
blocking-b2g: --- → 1.3T?
(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.
Reporter | ||
Comment 10•11 years ago
|
||
(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)
Updated•11 years ago
|
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
Comment 12•11 years ago
|
||
oops, I think it should not be the same issue from comment 3, my mistake.
Reopened now
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Comment 13•11 years ago
|
||
George was traced the code about the logic of homescreen page transition. He's helping on digging more hint.
Flags: needinfo?(gduan)
Comment 14•11 years ago
|
||
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)
Assignee | ||
Comment 15•11 years ago
|
||
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)
Comment 16•11 years ago
|
||
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)
Comment 17•11 years ago
|
||
(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)
Comment 18•11 years ago
|
||
(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.
Comment 19•11 years ago
|
||
(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.
Assignee | ||
Comment 20•11 years ago
|
||
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 21•11 years ago
|
||
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+
Assignee | ||
Comment 22•11 years ago
|
||
Sorry, I should merge to master first.
Assignee | ||
Comment 23•11 years ago
|
||
Travis is all green.
merge to master:
https://github.com/mozilla-b2g/gaia/commit/ef6fdfd09bbd0003db2e085efd6e0fe49d42aa18
Status: ASSIGNED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → FIXED
Comment 24•11 years ago
|
||
Please land it on v1.3t. Thanks.
Flags: needinfo?(styang)
Flags: needinfo?(jcheng)
Comment 25•11 years ago
|
||
https://github.com/mozilla-b2g/gaia/commit/ab6cbcaf15e624b309a6087e53e2005387eb1a71
I have merged this patch.
Reporter | ||
Comment 26•11 years ago
|
||
I also see this problem in Buri V1.4 build. Should we also merge this fix to v1.4?
Updated•11 years ago
|
Flags: needinfo?(styang)
Comment 27•11 years ago
|
||
add some flags
blocking-b2g: 1.3T? → 1.3T+
status-b2g-v1.4:
--- → affected
Flags: needinfo?(jcheng)
Whiteboard: [1.4-approval-needed]
Comment 28•11 years ago
|
||
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
}
}
Comment 30•11 years ago
|
||
(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.
Comment 31•11 years ago
|
||
(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.
Assignee | ||
Comment 32•11 years ago
|
||
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)
Reporter | ||
Comment 33•11 years ago
|
||
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 → ---
Comment 34•11 years ago
|
||
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)
Comment 35•11 years ago
|
||
Agree with comment 34 - reclosing the bug here.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → FIXED
Comment 36•11 years ago
|
||
(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)
Reporter | ||
Updated•11 years ago
|
Flags: needinfo?(pcheng)
Reporter | ||
Comment 38•11 years ago
|
||
(In reply to James Zhang from comment #37)
> Please file a new bug, Peipei.
I cloned this bug to bug 995886
Flags: needinfo?(pcheng)
Comment 39•11 years ago
|
||
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.
Assignee | ||
Comment 40•11 years ago
|
||
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)
Comment 41•11 years ago
|
||
Please request approval-gaia-v1.4 on the appropriate PR in that case :)
Assignee | ||
Comment 43•11 years ago
|
||
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)
Comment 44•10 years ago
|
||
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)
Assignee | ||
Comment 45•10 years ago
|
||
Please see https://bugzilla.mozilla.org/show_bug.cgi?id=995886#c66 .
Tracking bug 991906 would be better.
Flags: needinfo?(gduan)
Comment 46•10 years ago
|
||
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.
Description
•