Closed
Bug 1131037
Opened 9 years ago
Closed 9 years ago
Homescreen settings sub-menu not displayed when going to homecreen and back
Categories
(Firefox OS Graveyard :: Gaia::Homescreen, defect)
Tracking
(b2g-v2.1 unaffected, b2g-v2.2 verified, b2g-master verified)
VERIFIED
FIXED
2.2 S6 (20feb)
Tracking | Status | |
---|---|---|
b2g-v2.1 | --- | unaffected |
b2g-v2.2 | --- | verified |
b2g-master | --- | verified |
People
(Reporter: RobertC, Assigned: kats)
References
Details
(Keywords: regression, Whiteboard: [fromAutomation])
Attachments
(6 files)
After changing the column layout from the homecreen setting menu then going to the homescreen and back the main settings menu is displayed instead of the homescreen sub-menu. Issue can be reproduced both manually and with automation. Reproduction rate: 5 out of 5 STR: 1. open settings app 2. tap on homescreen menu 3. change column layout (3 or 4 columns) 4. tap home button 5. tap settings Expected result: The homescreen sub-menu is displayed. Actual result: The main setting menu is displayed Build info v3.0 flame KK v18D-1 319MB: Gaia-Rev 0d7b35f23402c4cb29bca6b98280fec48a196dec Gecko-Rev https://hg.mozilla.org/mozilla-central/rev/3436787a82d0 Build-ID 20150209010211 Version 38.0a1 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20150209.045655 FW-Date Mon Feb 9 04:57:06 EST 2015 Bootloader L1TC100118D0
Comment 1•9 years ago
|
||
I cannot reproduce this issue on the Flame 3.0 The user is returned to the homescreen sub-menu when they go back into settings after following the steps above. 0/10 attempts Leaving qawanted for someone else to try. Device: Flame 3.0 BuildID: 20150209010211 Gaia: 0d7b35f23402c4cb29bca6b98280fec48a196dec Gecko: 3436787a82d0 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
Comment 2•9 years ago
|
||
I could NOT reproduce this issue on the Flame 3.0 build in comment 0 when either shallow or full flashing. (10 attempts each, 0/20 overall) The user is returned to the homescreen sub-menu when they go back into settings. Leaving qawanted for someone else to try. Device: Flame 3.0 BuildID: 20150209010211 Gaia: 0d7b35f23402c4cb29bca6b98280fec48a196dec Gecko: 3436787a82d0 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 Environmental Variables: Device: Flame 3.0 BuildID: 20150209010211 Gaia: 0d7b35f23402c4cb29bca6b98280fec48a196dec Gecko: 3436787a82d0 Version: 38.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0
Flags: needinfo?(ktucker)
Comment 3•9 years ago
|
||
This issue only reproduces when there are a lot of apps on the Homescreen. It looks like at step 4 the device goes through a low memory kill of opened apps in order to re-arrange Homescreen app icons. The reason why reporter was seeing this issue is because they were on a nightly engineering build where there are a lot of icons on Homescreen by default, and comment 1 was using a nightly user build where by default there's only a handful of apps. On a nightly user build, this issue can be reliably reproduced after installing 20 apps from Marketplace prior to attempting STR. On latest 3.0 master engineering build this issue reproduces 10/10. --- This issue also reproduces on Flame 2.2. Repro rate is 5/5. Device: Flame 2.2 (engineering build, 319MB mem) BuildID: 20150209063735 Gaia: df0acd45fa9ddad8f4f66e357967e53e888f3c7f Gecko: 26f1a37d754d Version: 37.0a2 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 ---- This issue does NOT reproduce on Flame 2.1. Following STR, Settings app doesn't get LMK'ed. Bug repro rate 0/10. Device: Flame 2.1 (engineering build, 319MB mem) BuildID: 20150209064034 Gaia: 6ef54895100d441b37e405a64636868303d56f4c Gecko: ab85d7772044 Version: 34.0 (2.1) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 ------ Working on getting the window now.
status-b2g-v2.1:
--- → unaffected
status-b2g-v2.2:
--- → affected
status-b2g-master:
--- → affected
Keywords: qawanted
QA Contact: pcheng
Comment 4•9 years ago
|
||
mozilla-inbound regression window: Last Working Environmental Variables: Device: Flame BuildID: 20150126062631 Gaia: 793773bb2944b42a85dd160049e605cbd880c4da Gecko: 0bec74187553 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 Environmental Variables: Device: Flame BuildID: 20150126065334 Gaia: 793773bb2944b42a85dd160049e605cbd880c4da Gecko: babd56077826 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 Gaia is the same so it's a Gecko issue. Gecko pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=0bec74187553&tochange=babd56077826 Possibly caused by Bug 1116588.
QA Whiteboard: [QAnalyst-Triage?]
Keywords: regressionwindow-wanted
Comment 5•9 years ago
|
||
Kartikaya, can you take a look at this? Looks like the work done on bug 1116588 might have caused this issue to occur.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker) → needinfo?(bugmail.mozilla)
Assignee | ||
Comment 6•9 years ago
|
||
I'm not able to reproduce this on a Flame 319 running master, with an extra 20 apps installed from the marketplace. I have a total of 70 icons on my homescreen. Pi Wei, how many icons did you have in total?
Flags: needinfo?(bugmail.mozilla) → needinfo?(pcheng)
Comment 7•9 years ago
|
||
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #6) > I'm not able to reproduce this on a Flame 319 running master, with an extra > 20 apps installed from the marketplace. I have a total of 70 icons on my > homescreen. Pi Wei, how many icons did you have in total? If you use an engineering build, it should reproduce without issue. I don't have icons collapsed, they're all expanded. I will try again with today's master and add a video later if you still can't reproduce. Keeping the NI for now.
Comment 8•9 years ago
|
||
Video: https://www.youtube.com/watch?v=s_UKavvx78o I counted 51 icons on Homescreen by default on an engieering build. Also attaching a logcat. Tested on: Device: Flame 3.0 Master (full flash, 319MB mem) BuildID: 20150209133034 Gaia: 0cf517083f7eb5fc269e1236edba50534f65e3cd Gecko: 2cb22c058add Gonk: e7c90613521145db090dd24147afd5ceb5703190 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
Flags: needinfo?(pcheng)
Assignee | ||
Comment 9•9 years ago
|
||
I'm able to reproduce this now. The cause is more or less what I was expecting - there are a few more layers being created after bug 1116588 landed which weren't being created before, and that's causing the extra memory usage. Whereas before we had 128 layers being created in the animation (in the run that I recorded anyway) we now have 141 layers. I'm attach the full display-list and layer dumps for reference.
Assignee | ||
Comment 10•9 years ago
|
||
I think the next step here is to find the items that have opacity:0 set on them and see if we can also make them pointer-events:none or just remove them entirely. That should then bring the memory usage back down.
Assignee | ||
Comment 11•9 years ago
|
||
I looked into this further and found one instance where an opacity:0 thing in the homescreen was also visibility:hidden. I filed bug 1134825 for optimizing that away in Gecko. All the rest of the opacity:0 items I found in the homescreen we cannot optimize away in Gecko unless we set pointer-events:none on them in gaia. I have a patch that does this locally and it fixes this bug, but I'm not sure if it will break homescreen use cases. I'll attach it anyway, and let the homescreen owners figure it out.
Blocks: 1116588
Component: Gaia::Settings → Gaia::Homescreen
Comment 12•9 years ago
|
||
Assignee | ||
Comment 13•9 years ago
|
||
Comment on attachment 8566769 [details] [review] [gaia] staktrace:animation > mozilla-b2g:master Any thoughts on this? I haven't really tested this except for checking that it fixes this bug by bringing down the peak memory usage during the icon-rearranging animation.
Attachment #8566769 -
Flags: review?(kgrandon)
Comment 14•9 years ago
|
||
Comment on attachment 8566769 [details] [review] [gaia] staktrace:animation > mozilla-b2g:master This looks fine to me, but I'd also like Chris to take a look so flipping review to him and leaving an F+. Thanks!
Attachment #8566769 -
Flags: review?(kgrandon)
Attachment #8566769 -
Flags: review?(chrislord.net)
Attachment #8566769 -
Flags: feedback+
Assignee | ||
Comment 15•9 years ago
|
||
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #11) > I looked into this further and found one instance where an opacity:0 thing > in the homescreen was also visibility:hidden. I filed bug 1134825 for > optimizing that away in Gecko. tn pointed out my patch on bug 1134825 was wrong so I wontfix'd that bug. However the gaia patch here is sufficient to fix this bug. In particular I think it was the #curtain div that was using up the most memory as it's a full-screen layer.
Comment 16•9 years ago
|
||
Comment on attachment 8566769 [details] [review] [gaia] staktrace:animation > mozilla-b2g:master This looks fine to me - also good to know... Funnily, I was under the impression that group backgrounds/shadows already had pointer-events: none, I wonder if that disappeared at some point...
Attachment #8566769 -
Flags: review?(chrislord.net) → review+
Assignee | ||
Updated•9 years ago
|
Assignee: nobody → bugmail.mozilla
Keywords: checkin-needed
Updated•9 years ago
|
Keywords: checkin-needed
Comment 17•9 years ago
|
||
Pull request has landed in master: https://github.com/mozilla-b2g/gaia/commit/f09993563fb5fec4393eb71816ce76cb00463190
Updated•9 years ago
|
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•9 years ago
|
Assignee | ||
Comment 18•9 years ago
|
||
qawanted to verify on the next build with the fix. Also please double-check that homescreen interactions all work ok.
Keywords: qawanted
Comment 19•9 years ago
|
||
Issue still reproduces on a b2g-inbound build that contains the patch. Repro rate is about 5/10, it's lower now, but definitely still repro'ing. Not sure how useful it is but attaching a logcat. Device: Flame 3.0 Master (KK, full flash, b2g-inbound eng build, 319MB mem) BuildID: 20150220094934 Gaia: 0aa1ec41da654503bbd04f1a33d1ff34dccfd8a5 Gecko: b9994aa86055 Gonk: e7c90613521145db090dd24147afd5ceb5703190 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
Comment 20•9 years ago
|
||
:Kartikaya, please see comment 19.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Flags: needinfo?(bugmail.mozilla)
Keywords: qawanted
Assignee | ||
Comment 21•9 years ago
|
||
I think we might just have to live with the remaining OOM-kills for now. There's not much else we can trim from the homescreen app without doing more invasive surgery there. Bug 1116588 will result in more transient memory usage during painting, and the homescreen animation is one of those places where it adds up just enough to manifest as OOM killing. It'll probably happen in other places as well and we can't avoid it completely. I did run through a number of cycles of changing the homescreen layout from 3-wide to 4-wide with firewatch running and the memory numbers never went completely out of control. There were peaks on app-switching like I would expect but it's not like we're leaking memory.
Flags: needinfo?(bugmail.mozilla)
Updated•9 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Assignee | ||
Comment 22•9 years ago
|
||
Chris, any objections to uplifting this to 2.2? Presumably it will improve the OOM-kill situation there as well.
Flags: needinfo?(chrislord.net)
Comment 23•9 years ago
|
||
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #22) > Chris, any objections to uplifting this to 2.2? Presumably it will improve > the OOM-kill situation there as well. No objections at all, I'm all for it :)
Flags: needinfo?(chrislord.net)
Assignee | ||
Comment 24•9 years ago
|
||
Comment on attachment 8566769 [details] [review] [gaia] staktrace:animation > mozilla-b2g:master [Approval Request Comment] [Bug caused by] (feature/regressing bug #): pre-existing, but exposed by bug 1116588 [User impact] if declined: homescreen uses more memory than it needs to, resulting in more frequent OOM-kills. [Testing completed]: has been baking on m-c for a while now [Risk to taking this patch] (and alternatives if risky): pretty low risk, just a few CSS changes, can be backed out easily if it causes problems [String changes made]: none
Attachment #8566769 -
Flags: approval-gaia-v2.2?
Updated•9 years ago
|
Attachment #8566769 -
Flags: approval-gaia-v2.2? → approval-gaia-v2.2+
Comment 25•9 years ago
|
||
v2.2: https://github.com/mozilla-b2g/gaia/commit/5af04fe0cd192ed6de56fa7582e679d861cd2729
Target Milestone: --- → 2.2 S6 (20feb)
Comment 26•9 years ago
|
||
This problem is verified pass on latest build of Flame 2.2 with extra 20 apps installed from the marketplace. See attachment: Flame2.2_video.MP4 Rate:0/20 The verify result on Flame 3.0 is the same with Comment 19. Leaving verifyme for 3.0 uplift/verification. Flame 2.2 build (319mb) (unaffected): Build ID 20150312002501 Gaia Revision 572d60e0a440ee4af50bc6b6adad8876eadbdb4d Gaia Date 2015-03-12 01:29:41 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/244e6ba3c20e Gecko Version 37.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150312.040315 Firmware Date Thu Mar 12 04:03:26 EDT 2015 Bootloader L1TC000118D0 Flame 3.0 build (319mb) (affected): Build ID 20150312160232 Gaia Revision eabe35cf054d47087b37c1ca7db8143717fbd7f3 Gaia Date 2015-03-12 18:01:49 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/42afc7ef5ccb Gecko Version 39.0a1 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150312.194521 Firmware Date Thu Mar 12 19:45:32 EDT 2015 Bootloader L1TC000118D0
Updated•9 years ago
|
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][MGSEI-Triage+]
Updated•9 years ago
|
Comment 27•9 years ago
|
||
This issue is verified fixed on the latest Flame and Spark 2.5 builds. The user is properly returned to the homescreen sub-menu in settings after changing the column layout with more than 20 marketplace apps installed to the homescreen. Environmental Variables: Device: Flame 2.5 BuildID: 20150820030207 Gaia: 89e0096a3de0378e3eda77e6a2a0bb5ca03eb8bb Gecko: 29b2df16e961fbe9a379362ecba6f888d1754bc3 Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd Version: 43.0a1 (2.5) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0 Environmental Variables: Device: Aries 2.5 BuildID: 20150820012109 Gaia: 89e0096a3de0378e3eda77e6a2a0bb5ca03eb8bb Gecko: 29b2df16e961fbe9a379362ecba6f888d1754bc3 Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd Version: 43.0a1 (2.5) Firmware Version: D5803_23.1.A.1.28_NCB.ftf User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+][MGSEI-Triage+] → [QAnalyst-Triage?][MGSEI-Triage+]
Flags: needinfo?(jmercado)
Keywords: verifyme
Updated•9 years ago
|
Updated•9 years ago
|
Flags: needinfo?(jmercado)
You need to log in
before you can comment on or make changes to this bug.
Description
•