1062527 - [Homescreen] Unable to launch apps after changing the date to a previous one

Status: VERIFIED FIXED

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

Description

[Seth Miko [:SMiko]]

Attachment: Date&Time.txt

Description:
The user is unable to launch apps from the home screen after setting the month and year to a previous one.

Repro Steps:
1: Update a Flame to 20140903000204
2: Open Settings > Date and Time and toggle off the Set automatically option
3: Select Date and change the month and year to anything prior to 2014
4: Select "OK"
5: Press the Home button to return to the home screen

Actual:
The user is unable to launch any apps

Expected:
The user is able to launch any app by tapping on it.

Flame 2.1(319mb)

Environmental Variables:
Device: Flame Master (319mb)
Build ID: 20140903000204
Gaia: fbb297c39aab5f17b179533d2a9a6c5166b2c197
Gecko: fb5e796da813
Version: 34.0a2 (Master)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Notes:
1: This issue does NOT occur when changing to a future date.
2: When this issue occurs, the user is able to launch apps again after scrolling on the home screen.

Repro frequency: 100%

See attached: logcat

Video clip: http://youtu.be/TP2isMZr6SQ

Comment 1

[Seth Miko [:SMiko]]

This issue DOES repro on Flame 2.2 (319mb), Open C 2.2, Flame 2.1(512mb), Open C 2.1, Flame 2.0(319mb) and Open C 2.0

Actual results: 
The user is unable to launch any apps after setting the date to a previous one

Flame 2.2 (319mb)

Environmental Variables:
Device: Flame 2.2 Master (319mb)
BuildID: 20140903040203
Gaia: 52670853c17fc0d3d33065c667c0ce124c93b98f
Gecko: e58842c764dd
Version: 35.0a1 (2.2 Master)
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Open C 2.2

Environmental Variables:
Device: Open_C 2.2 Master
BuildID: 20140903040203
Gaia: 52670853c17fc0d3d33065c667c0ce124c93b98f
Gecko: e58842c764dd
Version: 35.0a1 (2.2 Master)
Firmware: P821A10v1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Flame 2.1 (512mb)

Environmental Variables:
Device: Flame 2.1 (512mb)
Build ID: 20140903000204
Gaia: fbb297c39aab5f17b179533d2a9a6c5166b2c197
Gecko: fb5e796da813
Version: 34.0a2 (Master)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Open C 2.1

Environmental Variables:
Device: Open_C 2.1
Build ID: 20140903000204
Gaia: fbb297c39aab5f17b179533d2a9a6c5166b2c197
Gecko: fb5e796da813
Version: 34.0a2 (Master)
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Flame 2.0 (319mb)

Environmental Variables:
Device: Flame 2.0 (319mb)
BuildID: 20140903000206
Gaia: 449d8db9b3ea1f9262db822c37ef2143477172b7
Gecko: 13b41e22c8f6
Version: 32.0 (2.0)
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Open_C 2.0

Environmental Variables:
Device: Open_C 2.0
Build ID: 20140903000206
Gaia: 449d8db9b3ea1f9262db822c37ef2143477172b7
Gecko: 13b41e22c8f6
Version: 32.0 (2.0)
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0


This issue does NOT repro on Flame 1.4(319mb) or Open C 1.4

Actual result:
The user is able to launch apps after setting the date to a previous one.

Flame 1.4 (319mb)

Environmental Variables:
Device: Flame 1.4 (319mb)
Build ID: 20140903063011
Gaia: 2ee5b00bfbb8a67a967094804390b4afce8ecf54
Gecko: f5a75c0dd74e
Version: 30.0 (1.4)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Open C 1.4

Environmental Variables:
Device: Open_C 1.4
Build ID: 20140903063011
Gaia: 2ee5b00bfbb8a67a967094804390b4afce8ecf54
Gecko: f5a75c0dd74e
Version: 30.0 (1.4)
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Comment 2

[KTucker [:KTucker][Inactive 3/4/2016]]

[Blocking Requested - why for this release]:

This is a regression from 1.4 and the user is unable to launch any apps after changing date to one in the past so nominating this 2.0?

Comment 3

[howie [:howie]]

Triage: This seems like a homescreen issue, please have a look, thanks!

Comment 4

[Cristian Rodriguez (:crdlc)]

Attachment: Github pull request

Comment 5

[Cristian Rodriguez (:crdlc)]

Regression from bug 1050470

Comment 6

[Kevin Grandon :kgrandon]

Comment on attachment 8484873 [details]
Github pull request

I am bit confused here because I thought we changed apz to instead stop the scroll on tap did we not? Basically I am wondering if we can get away with removing the lastScrollTime instead of relying on visibilitychange events. What happens if we instead try removing the lastScrollTime logic all together?

Also, it is also potentially likely that we change the date while the homescreen is still active. If we do go down this road I think it would be safer to have some recovery timeout to reset the timer after the last scroll event.

What do you think?

Comment 7

[[:fabrice] Fabrice Desré]

We should move to use https://developer.mozilla.org/en-US/docs/Web/API/Performance.now which is monotonic and not affected by the system clock.

Comment 8

[Cristian Rodriguez (:crdlc)]

Kevin, I gonna check it without any logic related to lastScrollTime. If it works fine would be perfect, in another case, I will address the Fabrice's comment and yours. During morning I will update the pr with the new implementation

Comment 9

[Cristian Rodriguez (:crdlc)]

Comment on attachment 8484873 [details]
Github pull request

Hi Kevin,

   I have tested without our logic and the scroll is stopped with a tap but the app is also launched (the same happens in 2.0). So we have to keep our algorithm. BTW I updated the code with your suggestion and Fabrice's as well.

Thanks a lot

Comment 10

[Kevin Grandon :kgrandon]

In master: https://github.com/mozilla-b2g/gaia/commit/3a99e64704f1793f1bb547d19859d00721073a7c

Comment 11

[Kevin Grandon :kgrandon]

(This will automatically go to 2.1, correct?)

Comment 12

[[:fabrice] Fabrice Desré]

(In reply to Kevin Grandon :kgrandon from comment #11)
> (This will automatically go to 2.1, correct?)

Nothing goes automatically to 2.1. gaia-2.1 is like gecko-aurora, approval needed.

Comment 13

[Kevin Grandon :kgrandon]

Comment on attachment 8484873 [details]
Github pull request

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): Feature implementation.
[User impact] if declined: Edge case, but it can be a pretty bad experience for the user to get stuck in the homescreen.
[Testing completed]: Manual/unit tests.
[Risk to taking this patch] (and alternatives if risky): Low risk, small patch.
[String changes made]: None.

Comment 14

[Ryan VanderMeulen [:RyanVM]]

v2.1: https://github.com/mozilla-b2g/gaia/commit/98e6d28c55e699a153fdcbd0b5f2ae6cb188bb9e

Comment 15

[Ryan VanderMeulen [:RyanVM]]

Reverted from v2.1 for Gaia unit test failures.
v2.1: https://github.com/mozilla-b2g/gaia/commit/90812662b9e0d3aba88882290c08971fdff98515

https://tbpl.mozilla.org/php/getParsedLog.php?id=47716166&tree=Mozilla-Aurora

Comment 16

[Cristian Rodriguez (:crdlc)]

Ok, I gonna try to run the test in 2.1 and when they are fixed I will uplift it, thanks a lot

Comment 17

[Cristian Rodriguez (:crdlc)]

v2.1: https://github.com/mozilla-b2g/gaia/commit/c307ae5a8fdc5178bd79309d3b320ce633660fdb

Comment 18

[Cristian Rodriguez (:crdlc)]

Comment on attachment 8484873 [details]
Github pull request

Hi Fabrice, we've realized this bug is 2.0+ so I think that I have to ask for approval v2.0 here too, right?

Comment 19

[bhavana bajaj [:bajaj]]

Adding verifyme for QA to help verify this bug post 2.0 landing.

Comment 20

[Ryan VanderMeulen [:RyanVM]]

v2.0: https://github.com/mozilla-b2g/gaia/commit/4fa2b260eae6501ea950e3827bbc8ac5043dd799

Comment 21

[William Hsu [:whsu]]

Thanks everyone.
Verified this patch on Flame KK.

* Build Information:
 - Gaia        7edd3b0b9f65c3dde235c732d270e43e055a1254
 - Gecko       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/13e04ab68621
 - BuildID     20140914162307
 - Version     32.0
 - Base image  Flame KK
 - ro.build.version.incremental=27
 - ro.build.date=Thu Sep  4 14:59:02 CST 2014

Comment 22

[Lancy(Leave from Mozilla)]

Attachment: Verify_Video_Flame.MP4

This issue has been verified successfully on Flame 2.1 & 2.2.
See attachment: Verify_Video_Flame.MP4
Reproducing rate: 0/10

Flame v2.1 version:
Gaia-Rev        db2e84860f5a7cc334464618c6ea9e92ff82e9dd
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/211eae88f119
Build-ID        20141126001202
Version         34.0

Flame v2.2 version:
Gaia-Rev        41b7be7c67167f367c3c4982ff08651d55455373
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/ff4a63d66806
Build-ID        20141126160201
Version         36.0a1