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

Status: RESOLVED FIXED

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

Description

[Peipei Cheng (needinfo if you need my action)]

We still see this icon overlaping problem in latest build. The reproduce rate is much lower than previous builds. 
And user can swipe to recover homescreen icons except dock bar.

Unfortunately, we are still unable to find a consistent STR to reproduce this.


+++ This bug was initially created as a clone of Bug #990435 +++

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.

Comment 1

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

I think it has to do with the homescreen process getting killed by OOM and then locking the screen.  Not sure.  I still see this as well.  When this happens the dailer icon and the SMS icon disappear until reboot.

Comment 2

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

1.3T noming due to the missing icons.

Comment 3

[Joe Cheng [:jcheng] (please needinfo)]

ni? George

Comment 4

[(Inactive after June) George Duan [:gduan] [:喬智]]

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #1)
> I think it has to do with the homescreen process getting killed by OOM and
> then locking the screen.  Not sure.  I still see this as well.  When this
> happens the dailer icon and the SMS icon disappear until reboot.

Patch of bug 990435 is to fix https://bugzilla.mozilla.org/show_bug.cgi?id=990435#c17 . I think it's very simliar with what you stated in comment #1. I just tested on Tarako, and found out it's not reproducible.

That would be helpful if we can have a consistent STR.

Comment 5

[Peipei Cheng (needinfo if you need my action)]

Attachment: screenshot.png

spreadtrum saw this problem again after running monkey test.

Comment 6

[Marvin Khoo [:Marvin_Khoo]]

this shouldn't be Tarako specific issue, can someone verify / check it on other phone? i saw this symptom in Geekphone as well when download 1.3 nightly.

Comment 7

[Gregor Wagner [:gwagner]]

qawanted for STR.

George can you take this one since you worked on 990435?

Comment 8

[(Inactive after June) George Duan [:gduan] [:喬智]]

It looks interesting, since we only saw the position of dock bar is correct, which is different with bug 990435.

I cannot reproduce this bug. Plz kindly provide STR...

(In reply to pcheng from comment #5)
> Created attachment 8407358 [details]
> screenshot.png
> 
> spreadtrum saw this problem again after running monkey test.

Comment 9

[Mike Lien[:mlien]]

since now haven't a regular STR, please use steps-wanted on Keywords
but I think Jonh maybe has a brief steps to let reproduce rate be higher

John, do you have some reproduce steps about this issue.
I remember you have reply this kind of problem in the mail but not sure exactly.

Comment 10

[John Hammink]

Will check this again...need to see if it reproduces on buri.  I was getting the screen randomly when the phone was in an OOM state.

Comment 13

[yang.zhao]

(In reply to George Duan [:gduan] [:喬智] from comment #8)
> It looks interesting, since we only saw the position of dock bar is correct,
> which is different with bug 990435.
> 
> I cannot reproduce this bug. Plz kindly provide STR...
> 

Hi,George
    I will add some log for debugging once the issue happens again,do you have any suggestions for adding log?Such as print out the windowwidth or something else?

Comment 14

[yang.zhao]

Attachment: Phone_1_screenshot_appmanager

Comment 15

[yang.zhao]

Attachment: Phone_1_screenshot

Comment 16

[yang.zhao]

Attachment: Phone_2_screenshot_appmanager

Comment 17

[yang.zhao]

Attachment: Phone_2_screenshot

Comment 18

[Tzu-Lin Huang [:dwi2][:tzhuang]]

It's not dupe of bug 996514 (Bug symptoms are different). Reopen.

Comment 19

[yang.zhao]

We have two phones' homescreen overlapped after running monkey test.They both turn normal when sliding the homescreen,but the dock icons are still in wrong place.The attachments are the screenshots of the two phones and app-manager,they have a little differenc:there are only 3 '<li>' under '<footer> <ol>' on Phone_2,missing one <li>,you could see it from Phone_2_screenshot_appmanager.

hi,Tzu-Lin
    Please help to check it and give me a log patch for helping afford more information once the issue occurs again.Thank you.

Comment 20

[Peipei Cheng (needinfo if you need my action)]

is it related to Bug 991906 - [B2G][Homescreen] Long pressing an App that opened in Landscape mode will cause the Dock apps to shift ?

Comment 21

[Peipei Cheng (needinfo if you need my action)]

new monkey test log can be found here: https://www.dropbox.com/s/1ahb3o2xz1ohrtw/overlaphomescreen.zip

Comment 22

[(Inactive after June) George Duan [:gduan] [:喬智]]

Could you try to reproduce it with commit of bug 991906?

(In reply to yang.zhao from comment #13)
> (In reply to George Duan [:gduan] [:喬智] from comment #8)
> > It looks interesting, since we only saw the position of dock bar is correct,
> > which is different with bug 990435.
> > 
> > I cannot reproduce this bug. Plz kindly provide STR...
> > 
> 
> Hi,George
>     I will add some log for debugging once the issue happens again,do you
> have any suggestions for adding log?Such as print out the windowwidth or
> something else?

Comment 23

[yang.zhao]

(In reply to George Duan [:gduan] [:喬智] from comment #22)
> Could you try to reproduce it with commit of bug 991906?
> 
Since  bug 991906 doesn't uplift to v1.3t and this issue doesn't have a STR.

James,
   Shall we uplifts bug 991906 patch to v1.3t ?
> (In reply to yang.zhao from comment #13)
> > (In reply to George Duan [:gduan] [:喬智] from comment #8)
> > > It looks interesting, since we only saw the position of dock bar is correct,
> > > which is different with bug 990435.
> > > 
> > > I cannot reproduce this bug. Plz kindly provide STR...
> > > 
> > 
> > Hi,George
> >     I will add some log for debugging once the issue happens again,do you
> > have any suggestions for adding log?Such as print out the windowwidth or
> > something else?

Comment 24

[Jason Smith [:jsmith]]

Readding steps-wanted to continue working on getting reproducible STR.

Comment 25

[James Zhang (Spreadtrum)]

yang, land on monkey build to test.

Comment 26

[yang.zhao]

(In reply to James Zhang from comment #25)
> yang, land on monkey build to test.

Have conflicts,need a new patch for v1.3t.

Comment 27

[Luke Chang [:lchang] (inactive)]

Attachment: Bug-991906-uplifted.patch

I've resolved the conflicts from bug 991906. You can try this patch first.

Comment 28

[James Zhang (Spreadtrum)]

Yang, please land it.

Comment 29

[jcastro]

Being in the Contacts app while the phone goes to sleep/unlocked can cause this issue. I have had a repro rate of 1/15 attempts.

Repro Steps:
1) Update a tarako to BuildID: 20140424014003
2) Go to settings > Display > Set to 1 minute
3) Hit home button
4) Hit contacts
5) let phone go to sleep
6) Wake the phone > Unlock the phone
7) Repeat steps 4 - 6 until the bug is observed

I have attached a screenshot, firewatch log, and logcat. All tagged with my user name 'Jcastro'

1.3t Environmental Variables:
Device: tarako 1.3t MOZ
BuildID: 20140424014003
Gaia: 706f474230432c8cb01e124aee2c055ec902aa1d
Gecko: 26ef3dded9ff
Version: 28.1
Firmware Version: SP6821a-4-18

Comment 30

[jcastro]

Attachment: Jcastro_firewatch_Icon)Overlap.txt

Comment 31

[jcastro]

Attachment: Jcastro_Icon_Overlap_Logcat.txt

Comment 32

[jcastro]

Attachment: Jcastro_OverlappingIcons.png

Comment 33

[yang.zhao]

(In reply to James Zhang from comment #28)
> Yang, please land it.
Land it under monkey_test folder.
commit:ed072a5278d5447b8253039bf2e1c2afea3caf10

Comment 34

[Keven Kuo [:kkuo]]

Hi! Luke,

Assign this case to you, since you are working on it.

--
Keven

Comment 35

[Luke Chang [:lchang] (inactive)]

(In reply to yang.zhao from comment #33)
> Land it under monkey_test folder.
> commit:ed072a5278d5447b8253039bf2e1c2afea3caf10

Hi Yang, Does it work?

Comment 36

[James Zhang (Spreadtrum)]

We need monkey test 48 hours to verify.
Thomas, please run monkey test on your side.

Comment 37

[yang.zhao]

(In reply to Luke Chang [:lchang] from comment #35)
> (In reply to yang.zhao from comment #33)
> > Land it under monkey_test folder.
> > commit:ed072a5278d5447b8253039bf2e1c2afea3caf10
> 
> Hi Yang, Does it work?

Please see comment #36

Comment 38

[James Zhang (Spreadtrum)]

We can still meet this issue.

Comment 39

[Tzu-Lin Huang [:dwi2][:tzhuang]]

Hi Yang Zhao,

Could you provide adb log and screenshot of app-manager to display DOM structure in Homescreen? 
(Same as you did in bug 990435)

Thanks

Comment 40

[yang.zhao]

(In reply to Tzu-Lin Huang [:dwi2][:tzhuang] from comment #39)
> Hi Yang Zhao,
> 
> Could you provide adb log and screenshot of app-manager to display DOM
> structure in Homescreen? 
> (Same as you did in bug 990435)
> 
> Thanks
Sorry,I didn' get the phone.
Please see comment 31 32 33 to see if that could help.

Comment 41

[bhavana bajaj [:bajaj]]

blocking as luke is trying to get this resolved, if Luke patch does not help here we and we don't get STR until then we should unblock this.

Comment 42

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

1. install a webapp or add homescreen.
2. LMK a lot (ie launch facebook app and scroll down several times, or launch gallery app and edit lots of images)
3. let the device sleep
4. wake and unlock

Comment 43

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

not sure if bug 996514 is related or not...

Comment 44

[Luke Chang [:lchang] (inactive)]

Hi Yang,

Since bug 996514 has been landed, could you try to run the latest version with the patch in comment 27 and see if we can still meet this issue or not? Thanks.

Comment 45

[yang.zhao]

Attachment: bug293700_workaround.patch

In fact ,I don't think this is the same bug with bug 996514.
And I want to try this workaround.What do you think of it?

Comment 46

[Luke Chang [:lchang] (inactive)]

Ok, let's try it first.

Comment 47

[Luke Chang [:lchang] (inactive)]

Attachment: Patch for watching the movement of the dock

If you can still meet this issue, please merge this patch and dump the log when you see the dock is in the wrong position. It would be better if you can also attach a screenshot of the AppManager just like comment 14 and comment 16. Thanks.

Comment 48

[Luke Chang [:lchang] (inactive)]

Hi Yang,

In order to describe this bug more accurately, could you please help me confirm that the problem you can still reproduce is like attachment 8399831 [details], attachment 8411602 [details] or both?

Comment 49

[James Zhang (Spreadtrum)]

If we meet attachment 8411602 [details] first, then move homescreen page, we will meet attachment 8399831 [details] issue, dock ion disappear.

Comment 50

[yang.zhao]

(In reply to Luke Chang [:lchang] from comment #48)
> Hi Yang,
> 
> In order to describe this bug more accurately, could you please help me
> confirm that the problem you can still reproduce is like attachment 8399831 [details]
> [details], attachment 8411602 [details] or both?
The issue reproduced like attachment 8399831 [details],but when we move homescreen page,the page will recover to normal,but the dock couldn't recover,like attachment 8411602 [details].

Comment 51

[James Zhang (Spreadtrum)]

We don't meeting this issue with yang.zhao's patch by 7x15 hours monkey test.

Comment 52

[Keven Kuo [:kkuo]]

Hi! Luke,

Per our discussion, please help to suggest a review for Yang's patch.
Thanks.

--
Keven

Comment 53

[Luke Chang [:lchang] (inactive)]

Comment on attachment 8417235 [details] [diff] [review]
bug293700_workaround.patch

Hi Christian,

This patch seems working. Could you please help to review this patch? It's a tarako-specific patch so we will land it in v1.3t branch only. Thanks a lot.

Comment 54

[Cristian Rodriguez (:crdlc)]

Comment on attachment 8417235 [details] [diff] [review]
bug293700_workaround.patch

Review of attachment 8417235 [details] [diff] [review]:
-----------------------------------------------------------------

In the end we have a workaround with hardcoded values so I think that we could save memory with the suggestions

::: apps/homescreen/js/dock.js
@@ +9,4 @@
>    var MAX_NUM_ICONS = notTinyLayout ? 8 : 7;
>    var maxNumAppInViewPort = notTinyLayout ? 6 : 4, maxOffsetLeft;
>  
> +  var windowWidth = (function(){

If we use this workaround, I would like to implement

var windowWidth = 320; // Tarako width

::: apps/homescreen/js/grid.js
@@ +12,4 @@
>  
>    var SAVE_STATE_TIMEOUT = 100;
>    var BASE_HEIGHT = 460; // 480 - 20 (status bar height)
> +  var DEVICE_HEIGHT = (function(){

If we use this workaround, I would like to implement

var DEVICE_HEIGHT = 460; // Tarako height

@@ +50,4 @@
>    var launchPathBlacklist = [];
>  
>    var container;
> +  var windowWidth = (function(){

The same here

Comment 55

[Cristian Rodriguez (:crdlc)]

Comment on attachment 8417235 [details] [diff] [review]
bug293700_workaround.patch

Request to me a review again after addressing/answering comments

Comment 56

[Luke Chang [:lchang] (inactive)]

Attachment: Pull Request 18983

Hi Cristian,

Thanks for your quick reply.


Hi Yang,

I've attached the pull request based on Cristian's suggestion. Could you help to  determine if it works or not. Thanks.

Comment 57

[Cristian Rodriguez (:crdlc)]

+1 with this solution! 10x

(In reply to Luke Chang [:lchang] from comment #56)
> Created attachment 8417955 [details] [review]
> Pull Request 18983
> 
> Hi Cristian,
> 
> Thanks for your quick reply.
> 
> 
> Hi Yang,
> 
> I've attached the pull request based on Cristian's suggestion. Could you
> help to  determine if it works or not. Thanks.

Comment 58

[yang.zhao]

(In reply to Luke Chang [:lchang] from comment #56)
> Created attachment 8417955 [details] [review]
> Pull Request 18983
> 
> Hi Cristian,
> 
> Thanks for your quick reply.
> 
> 
> Hi Yang,
> 
> I've attached the pull request based on Cristian's suggestion. Could you
> help to  determine if it works or not. Thanks.

Ok.

Comment 59

[James Zhang (Spreadtrum)]

Yang, land WIP on my side and run monkey to verify.

Comment 60

[yang.zhao]

(In reply to Luke Chang [:lchang] from comment #56)
> Created attachment 8417955 [details] [review]
> Pull Request 18983
> 
> Hi Cristian,
> 
> Thanks for your quick reply.
> 
> 
> Hi Yang,
> 
> I've attached the pull request based on Cristian's suggestion. Could you
> help to  determine if it works or not. Thanks.

Already patched the pull request on our build version to verify.
But your pull requests' trvavis is failed.Could you help to resolve the failed Travis first so we could uplifts the pull request  to v1.3t ? Thank you very much!

Comment 61

[Keven Kuo [:kkuo]]

Hi! Luke,

Could you help on Travis fail part? Thanks

--
Keven

Comment 62

[Luke Chang [:lchang] (inactive)]

Comment on attachment 8417955 [details] [review]
Pull Request 18983

Travis passed: https://travis-ci.org/mozilla-b2g/gaia/builds/24523421

Hi Cristian, Could you help to review it again? Thanks.

Comment 63

[Cristian Rodriguez (:crdlc)]

Comment on attachment 8417955 [details] [review]
Pull Request 18983

Perfect! Thanks a lot

Comment 64

[Luke Chang [:lchang] (inactive)]

Cristian, thanks again!

merged in gaia v1.3t branch:
https://github.com/mozilla-b2g/gaia/commit/25a17d9d7143977ea9a81ed310098e326609d248

Comment 65

[Ivan Tsay (:ITsay)]

Hi Luke,

Does this bug affect v1.4 as well? If so, we will need patch to be uplifted to v1.4.

Comment 66

[Luke Chang [:lchang] (inactive)]

Hi Ivan,

I can't affirm if v1.4 is affected or not. However, the patch here is just a workaround and is specific to tarako only so it can't be uplifted to any other branches.

I recommend tracking Bug 991906 because they have much similar symptom.

Comment 67

[Keven Kuo [:kkuo]]

Agree with Luke. This patch is just a hardcode based on Tarako's screen resolution.Can't be uplifted to other branch.

--
Keven

Comment 68

[James Zhang (Spreadtrum)]

We can meet the same issue on dolphin.

Comment 69

[Jan Jongboom [:janjongboom] (inactive)]

Do we need the height as well for this patch to work? because if we only need the width for now we can use |screen.width| and uplift that to 1.4. Also works when not visible.

Comment 70

[yang.zhao]

(In reply to James Zhang (Spreadtrum) from comment #68)
> We can meet the same issue on dolphin.
Maybe we can try this patch first: 
attachment 8412434 [details] [diff] [review] [diff] [review]
Bug-991906-uplifted.patch

Since this patch is already landed on master,if the patch could resolve the overlapped issue on v1.4,then we don't need the hardcode.

Comment 71

[Cristian Rodriguez (:crdlc)]

We can wait for Yang says. If it would not work, we can follow the Jan's approach

Comment 72

[yang.zhao]

(In reply to Cristian Rodriguez (:crdlc) from comment #71)
> We can wait for Yang says. If it would not work, we can follow the Jan's
> approach
I've applied it on dolphine ,but it's still happend with STR ,please see bug 1029306 for more detail.And flame with v1.4 version also has this issue.

Comment 73

[yang.zhao]

Maybe the last method is using hard code on v1.4 ,like Tarako. But actually it's not a good idea.

Comment 74

[Cristian Rodriguez (:crdlc)]

If you applied the patch of bug 991906 and you have the same issue, I cannot help you because I don't have neither dolphine nor flame

Comment 75

[Cristian Rodriguez (:crdlc)]

Maybe you can use screen.width and screen.height in all places in v1.4 instead of using the variable calculated when libraries are loaded

Comment 76

[Jan Jongboom [:janjongboom] (inactive)]

I can reproduce on Flame 1.4 both without and with bug 991906, so let me steal & reopen this for 1.4.

Comment 77

[Jan Jongboom [:janjongboom] (inactive)]

Oh the overlapping is gone with bug 991906, the icons are just completely wrong size.

Comment 78

[Jan Jongboom [:janjongboom] (inactive)]

Attachment: Patch for v1.4

Alright, so I fixed the problem but I don't know if you're gonna like it, so asking both crldc and timdream for feedback as this patch both involves homescreen & system.

The first part is easy. After being killed the initial innerWidth of the homescreen is 0px. We use this value for a bunch of things, and we don't outline correctly. It's easily fixed by routing all requests for width and height through the Screen Helper. Then in screen helper we initialize the width and height with correct values derived of window.screen when innerWidth and innerHeight return 0.

Now this fixed most stuff, but not everything as icon sizes are sometimes way too big. I tracked it down to the window width going like this (only with screen off): 0px (initial) -> 980px (resize event) -> 320px (resize event). During the time between 980 and 320 we figure out if we run on a tablet or desktop and set the icon size to 90px. And thus the render is incorrect.

The size is always reported as 980x480px, so it makes no sense at all (normal value on Flame is 320x549). It's easily verified by adding this to page.js and killing the homescreen a couple of times with screen off:

window.addEventListener('resize', function() {
  dump('[PAGE.JS] resize ' + window.innerWidth + ' ' + window.innerHeight + '\n');
})

Now the system app does nothing special, like resizing or whatever, but I think Gecko just starts rendering the iframe and resizes it to the correct size later when reflow can happen. Or something. Tim might be able to shine some light on it.

When I do a sync reflow right after adding the iframe to the body the problem is gone, so that adds to the theory; but it's dirty as shit... https://github.com/comoyo/gaia/commit/8c5f53dcf4dd233acca89f4ae13284b338550e68#diff-cfa1d9813ade22ddb10164655efc52b9R499

Comment 79

[Cristian Rodriguez (:crdlc)]

Comment on attachment 8445101 [details] [review]
Patch for v1.4

LGTM the homescreen part, basically you took the screen helper in master and added the screen values. I understand the problem and I am not against your patch

Comment 80

[Wayne Chang [:wchang]]

Hi Jan,

Since this was fixed already without problem for 1.3T, we'd keep this as resolved fixed. Please set your 1.4 patch to request 1.4 approval so it gets landed to 1.4

Since we won't longer have a dolphin branch now we can land this directly to 1.4.

Comment 81

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 8445101 [details] [review]
Patch for v1.4

Jan,

If you are uplifting bug 991906 please do that there. Let's not land two bugs in one pull request.

As of the app window part, I suspect you have found a workaround for bug 1007595. In most cases if we need that for 1.4 you probably need that too in 2.0 and 2.1 too. I also think your comment should be more descriptive.

I will r+ a patch when above are fixed, i.e.
1) without the commit from bug 991906
2) with a descriptive comment.
3) applies to 1.4/2.0/master.

Thanks!

Comment 82

[Jan Jongboom [:janjongboom] (inactive)]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #81)
> Comment on attachment 8445101 [details] [review]
> Patch for v1.4
> 
> Jan,
> 
> If you are uplifting bug 991906 please do that there. Let's not land two
> bugs in one pull request.

Sure, but I can't remove the commit from bug 991906 from the PR because it wouldn't work, as the screen_helper.js is added in there. If we land 991906 on 1.4 the commit will disappear from the PR.

Anyway, I'll add the patch for master because 991906 is already in there and keep the 1.4 as is.

Comment 83

[yang.zhao]

(In reply to Jan Jongboom [:janjongboom] (Telenor) from comment #82)
> (In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from
> comment #81)
> > Comment on attachment 8445101 [details] [review]
> > Patch for v1.4
> > 
> > Jan,
> > 
> > If you are uplifting bug 991906 please do that there. Let's not land two
> > bugs in one pull request.
> 
> Sure, but I can't remove the commit from bug 991906 from the PR because it
> wouldn't work, as the screen_helper.js is added in there. If we land 991906
> on 1.4 the commit will disappear from the PR.
> 
> Anyway, I'll add the patch for master because 991906 is already in there and
> keep the 1.4 as is.
Please help to land it on v1.4. Thank you !

Comment 84

[Jan Jongboom [:janjongboom] (inactive)]

Attachment: Patch for master

This is the master patch

Comment 85

[Jan Jongboom [:janjongboom] (inactive)]

Comment on attachment 8445101 [details] [review]
Patch for v1.4

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): Initial implementation
[User impact] if declined: Homescreen can be rendered useless when homescreen gets OOMed when screen is off
[Testing completed]: A similar patch was tested on Tarako, but no.
[Risk to taking this patch] (and alternatives if risky): Performance regression when opening apps due to new sync reflow.
[String changes made]: None

Comment 86

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 8445101 [details] [review]
Patch for v1.4

Let's land this on master first and have this and bug 991906 uplifted in order to 1.4 when they are approved.

Comment 87

[Preeti Raghunath(:Preeti)]

Awaiting for results per testing on master

Comment 88

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 8445740 [details] [review]
Patch for master

You don't need to create multiple pull requests for branches if the patch is the same, but yes, we should land on master first.

Comment 89

[Jan Jongboom [:janjongboom] (inactive)]

I had to because the patch doesn't merge cleanly on both master & 1.4.

Landed on master https://github.com/mozilla-b2g/gaia/commit/1c1e373aa6ae5a33245f80efdb5ed7e17e26ab30

Comment 91

[Ivan Tsay (:ITsay)]

Hi Lawrence,

please help to check this bug for the 1.4 uplift approval. Thanks.

Comment 92

[Lawrence Mandel [:lmandel] (use needinfo)]

Comment on attachment 8445101 [details] [review]
Patch for v1.4

Approved for 1.4.

Comment 93

[Ryan VanderMeulen [:RyanVM]]

v1.4: https://github.com/mozilla-b2g/gaia/commit/c36c0a721ce3d509ac6ca6ea173ffa339679f47e

Does this need to land on v2.0 as well? If so, please nominate it as such? :)

Comment 94

[Jan Jongboom [:janjongboom] (inactive)]

Comment on attachment 8445740 [details] [review]
Patch for master

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #):
[User impact] if declined:
[Testing completed]:
[Risk to taking this patch] (and alternatives if risky):
[String changes made]:

Comment 95

[Ryan VanderMeulen [:RyanVM]]

v2.0: https://github.com/mozilla-b2g/gaia/commit/03c90c2bff2ac5ccb4db61939417ed7a20c5a8eb

Comment 97

[Sue]

Attachment: verify_video.MP4

This issue has been verified successfully on Flame v2.0 & v2.1
STR:
1. Put device to sleep for a long time (over 10 minutes).
2. Wake device up and unlock screen.
**Homescreen displayed correctly.
Note: We also verified comment 29 many times, and everytime, homescreen displayed correctly.
See attachment: verify_video.MP4
Reproducing rate: 0/5
Flame 2.0 versions:
Gaia-Rev        8d1e868864c8a8f1e037685f0656d1da70d08c06
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/c756bd8bf3c3
Build-ID        20141201000201
Version         32.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141201.034308
FW-Date         Mon Dec  1 03:43:18 EST 2014
Bootloader      L1TC00011880

Flame 2.1 versions:
Gaia-Rev        ccb49abe412c978a4045f0c75abff534372716c4
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/18fb67530b22
Build-ID        20141201001201
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141201.034405
FW-Date         Mon Dec  1 03:44:15 EST 2014
Bootloader      L1TC00011880