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)
Tracking
(blocking-b2g:2.0+, b2g-v1.4 unaffected, b2g-v2.0 verified, b2g-v2.1 verified, b2g-v2.2 verified)
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)
272.57 KB,
text/plain
|
Details | |
190 bytes,
text/html
|
kgrandon
:
review+
bajaj
:
approval-gaia-v2.0+
fabrice
:
approval-gaia-v2.1+
|
Details |
2.58 MB,
video/mp4
|
Details |
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
Reporter | ||
Comment 1•10 years ago
|
||
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?]
status-b2g-v1.4:
--- → unaffected
status-b2g-v2.0:
--- → affected
status-b2g-v2.1:
--- → affected
Flags: needinfo?(ktucker)
Keywords: regression
Whiteboard: [2.1-exploratory]
Comment 2•10 years ago
|
||
[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)
Keywords: regressionwindow-wanted
Updated•10 years ago
|
QA Contact: rpribble
Comment 3•10 years ago
|
||
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 | ||
Updated•10 years ago
|
Assignee: nobody → crdlc
Status: NEW → ASSIGNED
Assignee | ||
Comment 4•10 years ago
|
||
Attachment #8484873 -
Flags: review?(kgrandon)
Updated•10 years ago
|
Keywords: regressionwindow-wanted
Updated•10 years ago
|
Whiteboard: [2.1-exploratory] → [systemsfe][2.1-exploratory]
Comment 6•10 years ago
|
||
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)
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage+][lead-review+]
Updated•10 years ago
|
blocking-b2g: 2.0? → 2.0+
Updated•10 years ago
|
Whiteboard: [systemsfe][2.1-exploratory] → [systemsfe][2.1-exploratory][systemsfe]
Target Milestone: --- → 2.1 S4 (12sep)
Comment 7•10 years ago
|
||
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.
Assignee | ||
Comment 8•10 years ago
|
||
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)
Assignee | ||
Comment 9•10 years ago
|
||
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)
Assignee | ||
Updated•10 years ago
|
Whiteboard: [systemsfe][2.1-exploratory][systemsfe] → [systemsfe][2.1-exploratory][systemsfe][ETA:09/12]
Assignee | ||
Updated•10 years ago
|
Whiteboard: [systemsfe][2.1-exploratory][systemsfe][ETA:09/12] → [systemsfe][2.1-exploratory][ETA:09/12]
Updated•10 years ago
|
Attachment #8484873 -
Flags: review?(kgrandon) → review+
Comment 10•10 years ago
|
||
In master: https://github.com/mozilla-b2g/gaia/commit/3a99e64704f1793f1bb547d19859d00721073a7c
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Comment 11•10 years ago
|
||
(This will automatically go to 2.1, correct?)
Comment 12•10 years ago
|
||
(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•10 years ago
|
||
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?
Updated•10 years ago
|
Attachment #8484873 -
Flags: approval-gaia-v2.1? → approval-gaia-v2.1+
Comment 14•10 years ago
|
||
v2.1: https://github.com/mozilla-b2g/gaia/commit/98e6d28c55e699a153fdcbd0b5f2ae6cb188bb9e
status-b2g-v2.2:
--- → fixed
Whiteboard: [systemsfe][2.1-exploratory][ETA:09/12] → [systemsfe][2.1-exploratory]
Comment 15•10 years ago
|
||
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
Assignee | ||
Comment 16•10 years ago
|
||
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)
Assignee | ||
Comment 17•10 years ago
|
||
v2.1: https://github.com/mozilla-b2g/gaia/commit/c307ae5a8fdc5178bd79309d3b320ce633660fdb
Assignee | ||
Comment 18•10 years ago
|
||
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)
Updated•10 years ago
|
Attachment #8484873 -
Flags: approval-gaia-v2.0?(fabrice) → approval-gaia-v2.0+
Comment 19•10 years ago
|
||
Adding verifyme for QA to help verify this bug post 2.0 landing.
Keywords: verifyme
Comment 20•10 years ago
|
||
v2.0: https://github.com/mozilla-b2g/gaia/commit/4fa2b260eae6501ea950e3827bbc8ac5043dd799
Keywords: branch-patch-needed
Comment 21•10 years ago
|
||
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
Comment 22•10 years ago
|
||
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
Updated•10 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•