Closed Bug 1062527 Opened 10 years ago Closed 10 years ago

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

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.0+, b2g-v1.4 unaffected, b2g-v2.0 verified, b2g-v2.1 verified, b2g-v2.2 verified)

VERIFIED FIXED
2.1 S4 (12sep)
blocking-b2g 2.0+
Tracking Status
b2g-v1.4 --- unaffected
b2g-v2.0 --- verified
b2g-v2.1 --- verified
b2g-v2.2 --- verified

People

(Reporter: smiko, Assigned: crdlc)

References

()

Details

(Keywords: regression, Whiteboard: [systemsfe][2.1-exploratory])

Attachments

(3 files)

Attached file 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
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
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: regression
Whiteboard: [2.1-exploratory]
[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?
blocking-b2g: --- → 2.0?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Contact: rpribble
Triage: This seems like a homescreen issue, please have a look, thanks!
Component: Gaia::Settings → Gaia::Homescreen
Summary: [Settings] Unable to launch apps after changing the date to a previous one → [Homescreen] Unable to launch apps after changing the date to a previous one
Assignee: nobody → crdlc
Status: NEW → ASSIGNED
Attached file Github pull request
Attachment #8484873 - Flags: review?(kgrandon)
Regression from bug 1050470
Depends on: 1050470
Whiteboard: [2.1-exploratory] → [systemsfe][2.1-exploratory]
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?
Attachment #8484873 - Flags: review?(kgrandon)
Flags: needinfo?(crdlc)
QA Whiteboard: [QAnalyst-Triage+][lead-review+]
blocking-b2g: 2.0? → 2.0+
Whiteboard: [systemsfe][2.1-exploratory] → [systemsfe][2.1-exploratory][systemsfe]
Target Milestone: --- → 2.1 S4 (12sep)
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.
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
Flags: needinfo?(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
Attachment #8484873 - Flags: review?(kgrandon)
Whiteboard: [systemsfe][2.1-exploratory][systemsfe] → [systemsfe][2.1-exploratory][systemsfe][ETA:09/12]
Whiteboard: [systemsfe][2.1-exploratory][systemsfe][ETA:09/12] → [systemsfe][2.1-exploratory][ETA:09/12]
Attachment #8484873 - Flags: review?(kgrandon) → review+
In master: https://github.com/mozilla-b2g/gaia/commit/3a99e64704f1793f1bb547d19859d00721073a7c
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
(This will automatically go to 2.1, correct?)
(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 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.
Attachment #8484873 - Flags: approval-gaia-v2.1?
Attachment #8484873 - Flags: approval-gaia-v2.1? → approval-gaia-v2.1+
v2.1: https://github.com/mozilla-b2g/gaia/commit/98e6d28c55e699a153fdcbd0b5f2ae6cb188bb9e
Whiteboard: [systemsfe][2.1-exploratory][ETA:09/12] → [systemsfe][2.1-exploratory]
Ok, I gonna try to run the test in 2.1 and when they are fixed I will uplift it, thanks a lot
Flags: needinfo?(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?
Attachment #8484873 - Flags: approval-gaia-v2.0?(fabrice)
Attachment #8484873 - Flags: approval-gaia-v2.0?(fabrice) → approval-gaia-v2.0+
Adding verifyme for QA to help verify this bug post 2.0 landing.
Keywords: verifyme
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
Status: RESOLVED → VERIFIED
Keywords: verifyme
Attached video 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
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: