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)

ARM
Gonk (Firefox OS)
defect
Not set
normal

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
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
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)
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.
Keywords: qawanted
QA Contact: pcheng
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?]
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)
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)
(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.
Attached file logcat on flame 3.0
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)
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.
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.
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 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 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+
(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 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: nobody → bugmail.mozilla
Keywords: checkin-needed
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
qawanted to verify on the next build with the fix. Also please double-check that homescreen interactions all work ok.
Keywords: qawanted
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
:Kartikaya, please see comment 19.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Flags: needinfo?(bugmail.mozilla)
Keywords: qawanted
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)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Chris, any objections to uplifting this to 2.2? Presumably it will improve the OOM-kill situation there as well.
Flags: needinfo?(chrislord.net)
(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)
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?
Attachment #8566769 - Flags: approval-gaia-v2.2? → approval-gaia-v2.2+
Keywords: verifyme
Attached video video
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
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][MGSEI-Triage+]
Blocks: 1150065
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
Flags: needinfo?(jmercado)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: