Closed Bug 1134649 Opened 9 years ago Closed 9 years ago
[Clock] App opens to blank interface; Alarm/Timer/Stopwatch tabs visible but cannot be navigated
14.31 KB, image/png
109.72 KB, text/plain
46 bytes, text/x-github-pull-request
|Details | Review|
46 bytes, text/x-github-pull-request
|Details | Review|
Description: The clock app is opening to broken UI. The clock display is not visible, only a blank screen. The bottom tabs for Alarm/Timer/Stopwatch can be seen with Alarm highlighted, however you cannot navigate between them. Repro Steps: 1) Update a Flame to 20150219010228 2) Open the Clock app. Actual: Clock app opens to broken UI. Expected: Clock app opens to usable UI. -------------------------------------------------- Environmental Variables: Device: Flame 3.0 Build ID: 20150219010228 Gaia: 620aecfde85a8b093247837c55de2708e22be1e1 Gecko: 360b5f211180 Gonk: e7c90613521145db090dd24147afd5ceb5703190 Version: 38.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0 Device: Flame 2.2 BuildID: 20150219002504 Gaia: ce79d35b92261e7cbfeaefebf87859ebeb0979b4 Gecko: 159a3907b959 Gonk: e7c90613521145db090dd24147afd5ceb5703190 Version: 37.0a2 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 **************************************************** Issue DOES NOT REPRO on 2.1 for flame devices: Results: Clock app opens to usable UI. Device: Flame 2.1 BuildID: 20150219001626 Gaia: a43e3cdf8783e9d87156d47b8bfff0f5f44f9e2e Gecko: 5653f229724f Gonk: e7c90613521145db090dd24147afd5ceb5703190 Version: 34.0 (2.1) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 -------------------------------------------------- Repro frequency: 5/5 See attached: screenshot logcat
QA Whiteboard: [QAnalyst-Triage?]
[Blocking Requested - why for this release]: Functional Regression of a core feature that fails smoke tests. Requesting a window.
Looking through the jenkins b2g-inbound.tinderbox smoke runs I've found this regression window: First Broken: Device firmware (base) L1TC100118D0 Device firmware (date) 18 Feb 2015 12:53:38 Device firmware (incremental) eng.cltbld.20150218.155328 Device firmware (release) 4.4.2 Device identifier flame Gaia date 18 Feb 2015 11:37:03 Gaia revision cb452d55651b Gecko build 20150218122736 Gecko revision b4d49f3dc153 Gecko version 38.0a1 http://jenkins1.qa.scl3.mozilla.com/job/flame-kk-319.b2g-inbound.tinderbox.ui.functional.smoke/2674/HTML_Report/ ----------------------------------------- Last Working: Device firmware (base) L1TC100118D0 Device firmware (date) 18 Feb 2015 12:27:02 Device firmware (incremental) eng.cltbld.20150218.152651 Device firmware (release) 4.4.2 Device identifier flame Gaia date 18 Feb 2015 09:13:33 Gaia revision 3cc2e71a5038 Gecko build 20150218114745 Gecko revision 57e1719e3d03 Gecko version 38.0a1 http://jenkins1.qa.scl3.mozilla.com/job/flame-kk-319.b2g-inbound.tinderbox.ui.functional.smoke/2673/HTML_Report/
I can reproduce this on v2.2, but not on master; looks to be a regression from the uplift of bug 1130975. Investigating.
Assignee: nobody → m
Attachment #8566616 - Flags: review?(jrburke)
Comment on attachment 8566616 [details] [review] [gaia] mcav:fix-clock-load-master > mozilla-b2g:master r+ on inspection and debug session in IRC.
Attachment #8566616 - Flags: review?(jrburke) → review+
This regression from bug 1130975 was missed in both the automated tests and manual testing because this bug only appears when building with GAIA_OPTIMIZE=1. GAIA_OPTIMIZE annoyingly comments out script includes in <head>, replacing them with a minified single file optimized include. This caused the optimized build to lose the "data-main" attribute which loads the application's script. However, this mangling does not occur when the script is in the BODY tag. This patch relocates the alameda.js include to the BODY, including the "defer" attribute to maintain the fix from bug 1130975, which was the reason it was moved in the first place. Thanks to :jrburke for debugging help.
Confirmed that the patch for Bug 1130975 is the cause of this issue. b2g-inbound regression window: Last Working Device: Flame 3.0 Master BuildID: 20150218114745 Gaia: 3cc2e71a5038f4e69a7304ee2daec5790a3c25c3 Gecko: 57e1719e3d03 Version: 38.0a1 (3.0 Master) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0 First Broken Device: Flame 3.0 Master BuildID: 20150218122736 Gaia: cb452d55651beb33ae19a513824ad79d61799495 Gecko: b4d49f3dc153 Version: 38.0a1 (3.0 Master) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0 Last Working Gaia First Broken Gecko - issue does NOT repro Gaia: 3cc2e71a5038f4e69a7304ee2daec5790a3c25c3 Gecko: b4d49f3dc153 Last Working Gecko First Broken Gaia - issue DOES repro Gaia: cb452d55651beb33ae19a513824ad79d61799495 Gecko: 57e1719e3d03 Gaia pushlog: https://github.com/mozilla-b2g/gaia/compare/3cc2e71a5038f4e69a7304ee2daec5790a3c25c3...cb452d55651beb33ae19a513824ad79d61799495
Comment on attachment 8566616 [details] [review] [gaia] mcav:fix-clock-load-master > mozilla-b2g:master [Approval Request Comment] Per Comment 8, this regression was missed in automated and manual testing because automated tests don't use GAIA_OPTIMIZE=1 and neither does "make reset-gaia". This patch, manually verified with GAIA_OPTIMIZE=1, resolves the regression. [Bug caused by] (feature/regressing bug #): bug 1130975 [User impact] if declined: The clock app won't load properly when built with GAIA_OPTIMIZE=1. [Testing completed]: Manually verified with GAIA_OPTIMIZE=1 [Risk to taking this patch] (and alternatives if risky): low [String changes made]: none
Attachment #8566616 - Flags: approval-gaia-v2.2?
We discussed this in the QA stand-up today and John's going to help verify this before I approve on the 2.2 branch.
blocking-b2g: 2.2? → 2.2+
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Verifying fix for 3.0 on flame devices, smoketest case returns to green. Results: Clock opens to usable UI. -------------------------------------------------- Environmental Variables: Device: Flame 3.0 BuildID: 20150220010206 Gaia: e4f7c67378e33e83f88d38ddb4a6c2cabf1423c3 Gecko: 1b4c5daa7b7a Gonk: e7c90613521145db090dd24147afd5ceb5703190 Version: 38.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0 --------------------------------------------------
just to note, this is an example of one way to verify patches before they land on a branch: In order to verify that the patch works: 1) flash a flame with the latest 2.2 eng build reason: to get the latest gonk/gecko ; engineering build as it has root access and simplifies things. 2) git clone -b v2.2 https://github.com/mozilla-b2g/gaia.git v2.2_gaia_git reason: need to get the latest gaia for v2.2, -b v2.2 signifies the branch; if you already have a gaia 2.2, then just do a "git pull" on it. 3) cd v2.2_gaia_git 4) git checkout -b fix-clock-load reason: branch out to a different branch to pull the patch in in case we need to reuse this local repo; this also autoswitches you to that branch after creating the branch. you can verify with: git branch 5) git pull https://github.com/mcav/gaia.git fix-clock-load reason: need to pull mcav's fix; should be fine so long as he didn't make any changes on top of this fix in the branch. Otherwise you would have to cherry pick the fix. 6) save the commit, if you're in vi then 'esc' :wq 7) MOZILLA_OFFICIAL=1 make install-gaia reason: to build and install gaia on the device. This assumes that your flame device is connected, awake, no screenlocked and has adb access.
I verified the 2.2 patch since I went this far to document the how to. Patch works, please approve for 2.2 landing.
As noted in other comments in this thread, either `PRODUCTION=1` or `GAIA_OPTIMIZE=1` should also be added to verify fixes. This bug will appear fixed *with or without* this patch unless that flag is set.
Ni :nhirata to confirm this was verified after the flag was set per comment #16 ?
I used make production this time around and the app doesn't look fixed with the 2.2 patch. Is there something else I need to pull?
Flags: needinfo?(nhirata.bugzilla) → needinfo?(m)
Guys, I don't want to be annoying but you're not following the rule where a patch gets backed out when it causes a regression. It's been five days since the bug was opened and I still can't use one of the most basic features of my phone even after the patch that caused it was identified. There's no hope of gathering a community of crazy people like me testing your software if you let critical bugs linger like this for so long. I'm on 2.2 by the way and this is not the only bug where I've noticed this.
Figured out what my issue was. It was a mismatch of gecko with the patch. The clock does work with this patch. Please uplift the fix.
Flags: needinfo?(m) → needinfo?(bbajaj)
Attachment #8566616 - Flags: approval-gaia-v2.2? → approval-gaia-v2.2+
I have verified this bug successfully on Flame 2.2 Device Info: Build ID 20150225162504 Gaia Revision e4bf968d5a7366e7bdc58f0fdba28b32e864bdf7 Gaia Date 2015-02-25 18:39:43 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/da6ac51f5113 Gecko Version 37.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150225.200419 Firmware Date Wed Feb 25 20:04:31 EST 2015 Bootloader L1TC000118D0
Checked the Automated report Oliver sent on February 19th, this was visible in the automation results.
Whiteboard: [3.0-Daily-Testing] → [3.0-Daily-Testing][fromAutomation]
You need to log in before you can comment on or make changes to this bug.