Martin Shuman [:Marty] Reporter
	Description • 9 years ago

Description:
After the user deletes a Marketplace app and restarts the device, the homescreen will have several broken UI features:
-Long pressing on any Homescreen icons results in text selection, blocking access to Homescreen Edit Mode. This can be worked around by collapsing and expanding an icon group.
-After entering edit mode, the header UI is displayed in the top left corner improperly.
-Previously deleted bookmarks are restored to the homescreen. Cannot be deleted again.
-Empty Icon groups from previously deleted Marketplace apps may reappear.
-The empty space below the icon groups is often missing.
-Long pressing empty space on the homescreen will not bring up Homescreen Settings.

These issues persist after subsequent device reboots.

Note: This issue seems to occur more frequently if the device has already been restarted before the marketplace app is deleted, but this does not always seem to be necessary.

Repro Steps:
1) Update a Flame to 20150413010203
2) Restart the Device
3) Open the Marketplace and install an app.
4) Return to the Homescreen and delete the app.
5) Restart the device.
6) Long press on an icon on the home menu to enter Edit Mode.
7) Collapse and expand an icon group on the homescreen, then long press on an icon again to enter Edit Mode.

Actual:
After the deleting a Marketplace app and performing a device restart, long pressing on Icons results in Text Selection instead of Edit Mode.  After collapsing an icon group, and then entering edit mode, the Header UI is broken.

Expected:
Deleting a Marketplace app and restarting the device causes to issues with homescreen functionality.

Environmental Variables:
Device: Flame 3.0 (319MB)(Full Flash)
Build ID: 20150413010203
Gaia: 3c68964cb9fdba7cf0f6829b7f44562acaf1f1d7
Gecko: 0a46652bd992
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 40.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

Repro frequency: 8/10
See attached: Screenshot, Logcat, Video (URL)

	Martin Shuman [:Marty] Reporter
	Comment 2 • 9 years ago

This issue does NOT occur on Flame 2.2 Builds.
Deleting a Marketplace app and restarting the device causes no issues with homescreen functionality.

Environmental Variables:
Device: Flame 2.2 (319MB)(Full Flash)
Build ID: 20150413002502
Gaia: cec00d643f517ffd96cde559cd3bbd43ab85816c
Gecko: 5005522fd68e
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 37.0 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

	Peter Bylenga [:PBylenga]
	Comment 3 • 9 years ago

[Blocking Requested - why for this release]:
Severe functional regression of a core feature.

Requesting a window.

	Brogan Zumwalt [Inactive]
	Comment 4 • 9 years ago

Reproducible by me in Nightly, but due to bug 1153976 was unable to get a central window (doesn't reproduce on central from 11th, and wasn't able to see if it occurs in today's central.) Will continue to work on tomorrow and will post window then.

	bhavana bajaj [:bajaj]
	Comment 5 • 9 years ago

Wil, any changes on the marketplace side that may be causing this ?

	bhavana bajaj [:bajaj]
	Comment 6 • 9 years ago

(In reply to bhavana bajaj [:bajaj] from comment #5)
> Wil, any changes on the marketplace side that may be causing this ?

Hmm, may not be a marketplace side as other versions of fxos arn't affected.

:gwagner, while we are trying to get window, do you have any ideas here, since this may be related to homescreen?

	Wil Clouser [:clouserw]
	Comment 7 • 9 years ago

(In reply to bhavana bajaj [:bajaj] from comment #5)
> Wil, any changes on the marketplace side that may be causing this ?

None that I know of.

	Jayme Mercado [:JMercado] (Inactive 3/4/2016)
	Comment 8 • 9 years ago

This issue is probably from the FX teams inbound.  I have checked both mozilla-inbound and b2g-inbound but they don't start occurring until after this issue was seen on central.  The other issue is that there was a large period of no builds on central followed by broke builds for a single day so the pushlog is pretty big.

Central Regression Window:

Last Working 
Environmental Variables:
Device: Flame 3.0
BuildID: 20150411033037
Gaia: 3c68964cb9fdba7cf0f6829b7f44562acaf1f1d7
Gecko: 0a46652bd992
Version: 40.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

First Broken 
Environmental Variables:
Device: Flame 3.0
BuildID: 20150414070710
Gaia: c8cb0c0ebb8dd1f5c0c9037e38f8e4b237beb77b
Gecko: 388f5861dc7d
Version: 40.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

Last Working gaia / First Broken gecko - Issue DOES occur
Gaia: 3c68964cb9fdba7cf0f6829b7f44562acaf1f1d7
Gecko: 388f5861dc7d

First Broken gaia / Last Working gecko - Issue does NOT occur
Gaia: c8cb0c0ebb8dd1f5c0c9037e38f8e4b237beb77b
Gecko: 0a46652bd992

Gecko Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0a46652bd992&tochange=388f5861dc7d

	Naoki Hirata :nhirata (please use needinfo instead of cc)
	Comment 9 • 9 years ago

hrm.  I made my own build and this doesn't appear...  I think it might have gotten fixed somewhere.

Serial: 351dd0f2 (State: device)
Build ID               20150415170948
Gaia Revision          3f704c06d52ecfcc3bf6333bae6fdf4bfdf0a08f
Gaia Date              2015-04-15 19:06:13
Gecko Revision         n/a
Gecko Version          40.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.nhirata.20150415.164510
Firmware Date          Wed Apr 15 17:08:58 PDT 2015
Bootloader             L1TC000118D0

	Naoki Hirata :nhirata (please use needinfo instead of cc)
	Comment 10 • 9 years ago

still occurs with build : 
Build ID               20150415160205
Gaia Revision          777d01f4a2c7b41c4b02e3cf87715714ccc0590b
Gaia Date              2015-04-15 17:20:09
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/53ceefb0e1c8
Gecko Version          40.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150415.204409
Firmware Date          Wed Apr 15 20:44:20 EDT 2015
Bootloader             L1TC000118D0

	Naoki Hirata :nhirata (please use needinfo instead of cc)
	Comment 11 • 9 years ago

looking at my gecko, it's the same gecko.  Looking at the gaia, ... well the difference shouldn't impact.
The main thing that's different is that I was using an eng gaia to test when I couldn't reproduce...  

The other part is that maybe I didn't do the steps correctly for my build?

	Naoki Hirata :nhirata (please use needinfo instead of cc)
	Comment 12 • 9 years ago

I flashed my own gaia on top again, with the gecko from the last build and it seems to be working fine.  I can't reproduce the issue for some reason.

I guess we'll try tomorrow's build and see if it still reproduces.  I'm baffled.

	Gregor Wagner [:gwagner]
	Comment 13 • 9 years ago

Is this still an issue?

	Martin Shuman [:Marty] Reporter
	Comment 14 • 9 years ago

This issue still occurs on the latest Flame 3.0 build.

Environmental Variables:
Device: Flame 3.0 (319MB)(Full Flash)
Build ID: 20150420010204
Gaia: cb41d8421da5dc4f16ea566ea2917a9b7f828154
Gecko: 50b95032152c
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 40.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

	Martin Shuman [:Marty] Reporter
	Comment 15 • 9 years ago

I was also able to reproduce this issue on a recent Central FlameKK Engineering build.
I've attached a logcat of the issue reproduced on this build.

Environmental Variables:
Device: Flame 3.0 (512MB)(Full Flash)
Build ID: 20150419202729
Gaia: cb41d8421da5dc4f16ea566ea2917a9b7f828154
Gecko: 392300a13ba2
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 40.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

	Gregor Wagner [:gwagner]
	Comment 16 • 9 years ago

Kevin, can you take this one?

	Naoki Hirata :nhirata (please use needinfo instead of cc)
	Comment 17 • 9 years ago

I think there's something busted about the releng gaia.

I can't reproduce this with a flash from the repo; I see some weird issues when flashing just the gaia or the full flash from releng...

	Naoki Hirata :nhirata (please use needinfo instead of cc)
	Comment 18 • 9 years ago

I doubt this would be the cause, I filed bug 1156683

	Kevin Grandon :kgrandon
	Comment 19 • 9 years ago

Based on what I see in the log, I think this bug is invalid. It appears that this may have been triggered by invalid gaia/gecko combinations - as it seems we're missing an API.

I'm adding qawanted to see if this still reproduces. This is the current error that I'm seeing:

04-20 19:23:23.465: W/Homescreen(1139): [JavaScript Error: "TypeError: this.app.getLocalizedValue is not a function" {file: "app://verticalhome.gaiamobile.org/gaia_build_defer_index.js" line: 521}]

	Naoki Hirata :nhirata (please use needinfo instead of cc)
	Comment 20 • 9 years ago

ya.  issue still happens.  Marty and I were able to reproduce the issue : 
W/Homescreen( 1107): [JavaScript Error: "TypeError: this.app.getLocalizedValue is not a function" {file: "app://verticalhome.gaiamobile.org/gaia_build_defer_index.js" line: 521}]
W/Homescreen( 1107): [JavaScript Error: "TypeError: this.element.parentNode is null" {file: "app://verticalhome.gaiamobile.org/gaia_build_defer_index.js" line: 495}]

	Naoki Hirata :nhirata (please use needinfo instead of cc)
	Comment 21 • 9 years ago

There's some other things in here : I/Gecko   (  209): Can't find symbol 'GetActiveUniformName'.
that make me worried about the build now.

I think it's valid bug; perhaps not in systemfe, possibly in releng.

	Gregor Wagner [:gwagner]
	Comment 22 • 9 years ago

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #21)
> There's some other things in here : I/Gecko   (  209): Can't find symbol
> 'GetActiveUniformName'.
> that make me worried about the build now.
> 
> I think it's valid bug; perhaps not in systemfe, possibly in releng.

Are you comparing the logcat of the 2 builds?

	Naoki Hirata :nhirata (please use needinfo instead of cc)
	Comment 23 • 9 years ago

Comparing the logcat from two different gaias; yes.  one from releng which uses the one from git.mozilla.org and one that I build myself using github.

	Naoki Hirata :nhirata (please use needinfo instead of cc)
	Comment 24 • 9 years ago

So for the releng build it pulls from the git.mozilla.org both gecko and gaia:

http://git.mozilla.org/?p=releases%2Fgecko.git&a=search&h=HEAD&st=commit&s=Bug+1118946+
http://git.mozilla.org/?p=releases/gecko.git;a=commit;h=df56e4d95794b3be5594cebff9117f5ffa8cd1e7
On the gecko side, the API should be there as well as the code on the gaia side.

Looking for the gaia side:
http://git.mozilla.org/?p=releases/gaia.git;a=commit;h=c70a699a9866be5af72ba9db0743c58f57f0903f

I am not sure if the API is missing, it seems like something might have broken the API calls instead...

	Naoki Hirata :nhirata (please use needinfo instead of cc)
	Comment 25 • 9 years ago

What's weird is I run into the issue where I can't even get to the edit screen when I do a fresh gaia pull ( ie clone github repro from scratch )

	Kevin Grandon :kgrandon
	Comment 26 • 9 years ago

Sounds like this should possibly be in the gecko Dom webapps component then?

	Naoki Hirata :nhirata (please use needinfo instead of cc)
	Comment 27 • 9 years ago

Not sure.  Though I noticed that b2g_sdk is at 39.0a1-2015-03-05-16-02-02

Shouldn't the xulrunner be 40? 
https://github.com/mozilla-b2g/gaia/blob/master/Makefile#L298

	Kevin Grandon :kgrandon
	Comment 28 • 9 years ago

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #27)
> Not sure.  Though I noticed that b2g_sdk is at 39.0a1-2015-03-05-16-02-02
> 
> Shouldn't the xulrunner be 40? 
> https://github.com/mozilla-b2g/gaia/blob/master/Makefile#L298

That shouldn't really impact this bug, but we should fix it in another bug.

	Naoki Hirata :nhirata (please use needinfo instead of cc)
	Comment 29 • 9 years ago

Filed bug 1157321

	[:fabrice] Fabrice Desré
	Comment 30 • 9 years ago

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #20)
> ya.  issue still happens.  Marty and I were able to reproduce the issue : 
> W/Homescreen( 1107): [JavaScript Error: "TypeError:
> this.app.getLocalizedValue is not a function" {file:
> "app://verticalhome.gaiamobile.org/gaia_build_defer_index.js" line: 521}]
> W/Homescreen( 1107): [JavaScript Error: "TypeError: this.element.parentNode
> is null" {file:
> "app://verticalhome.gaiamobile.org/gaia_build_defer_index.js" line: 495}]

If |this.app| is a real DOM application object there's no reason for `this.app.getLocalizedValue is not a function` to happen unless you have a really outdated gecko. The other option is that |this.app| is something else like a gaia wrapper.

	Gregor Wagner [:gwagner]
	Comment 31 • 9 years ago

Kevin, can you reproduce and help out?

	Kevin Grandon :kgrandon
	Comment 32 • 9 years ago

(In reply to Gregor Wagner [:gwagner] from comment #31)
> Kevin, can you reproduce and help out?

I'm currently unable to reproduce this, but can sit with Naoki this week and debug it.

	Doug Sherk (:drs) (inactive)
	Comment 33 • 9 years ago

Bhavana, this should block Spark.

	Peter Bylenga [:PBylenga]
	Comment 34 • 9 years ago

[Blocking Requested - why for this release]:
Nominating to block spark based on Comment 33.

	Naoki Hirata :nhirata (please use needinfo instead of cc)
	Comment 35 • 9 years ago

As stated in comment 12, you have to use a releng build in order to reproduce this issue.

spark+ since it was already a 3.0+ blocker.

	Joshua Mitchell (Inactive)
	Comment 36 • 9 years ago

Issue still reproduces in today's Flame KK 3.0 Nightly

Device: Flame 3.0 (KK - Nightly - Full Flash - 319mem)
Build ID: 20150428010206
Gaia: 0636405f0844bf32451a375b2d61a2b16fe33348
Gecko: caf25344f73e
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 40.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

	Jayme Mercado [:JMercado] (Inactive 3/4/2016)
	Comment 37 • 9 years ago

Removing qawanted per comment 36.  If you want more work let us know and add the tag again.

	Kevin Grandon :kgrandon
	Comment 38 • 9 years ago

Started looking into this, but no ETA yet. Still trying to reproduce this in a way where I can debug it.


(In reply to Jayme Mercado [:JMercado] from comment #8)
> Gecko Pushlog:
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=0a46652bd992&tochange=388f5861dc7d

Next step is to see if we can reproduce this manually with a full gecko build. Perhaps we can manally bisect this.

	Naoki Hirata :nhirata (please use needinfo instead of cc)
	Comment 39 • 9 years ago

I had tried to manually bisect it, the problem is that I could not reproduce the issue with my own builds.  I don't know if you will experience the same issue.  ( see comment 12 )

	Michael Henretty [:mikehenrty][:mhenretty]
	Comment 40 • 9 years ago

I'm seeing this on my dogfood device. Let me know if can help with the bisect process.

	Doug Sherk (:drs) (inactive)
	Comment 41 • 9 years ago

Gregor, could you help us find someone to look at this?

	Gregor Wagner [:gwagner]
	Comment 42 • 9 years ago

Chris can take a look.

	Chris Lord [:cwiiis] Assignee
	Comment 45 • 9 years ago

So I think the issue here is that verticalhome doesn't seem to handle apps being installed while it isn't running? I've run into this a few times while working on the new homescreen.

I tend to think that the way homescreen metadata is stored is a bit of a mess (and it leads to things like this), but I'll try to get this fixed.

	Chris Lord [:cwiiis] Assignee
	Comment 48 • 9 years ago

It's my top priority to fix this on Monday, seems spark changes are causing this bug to be hit a lot now.

	Chris Lord [:cwiiis] Assignee
	Comment 49 • 9 years ago

So I don't really fully understand this situation, but I think we may have handled it before and new icon/subtitle code broke that handling by assuming apps are always valid. Seems vertical home loads its own app store first before synchronising with the actual app store and removing deleted apps (instead of just never adding them to the grid).

Messing with the store code scares me, so this is the simplest fix I think, which restores normal behaviour. New home treats mozApps as the primary store and stores metadata in a secondary DB, so is unaffected by this.

	Kevin Grandon :kgrandon
	Comment 50 • 9 years ago

Comment on attachment 8622412 [details] [review]
Handle defunct apps in verticalhome

This looks pretty good to me - I do want to test it before leaving an R+, but I think this is on the right track.

Basically to speed up the vertical home screen we used an indexedDB for the initial render instead of mozApps - it was much faster at the time.

We just need to be sure that this doesn't break the initial render and we should be good to go.

	Kevin Grandon :kgrandon
	Comment 51 • 9 years ago

> New home treats mozApps as the primary store and stores metadata in a secondary DB

We used to do this as well, but due to performance blockers we had to change it. I'd suggest taking a perf measure with a few hundred apps installed - there is a tool to do so for you easily. I know some perf improvements have landed in mozapps lately, so this might be an acceptable approach now.

	Chris Lord [:cwiiis] Assignee
	Comment 52 • 9 years ago

(In reply to Kevin Grandon (PTO) :kgrandon from comment #51)
> > New home treats mozApps as the primary store and stores metadata in a secondary DB
> 
> We used to do this as well, but due to performance blockers we had to change
> it. I'd suggest taking a perf measure with a few hundred apps installed -
> there is a tool to do so for you easily. I know some perf improvements have
> landed in mozapps lately, so this might be an acceptable approach now.

This is interesting. I'd suggest that we should fix platform if that's the case though, we can't/shouldn't expect everyone to do this and it'll lead to bugs down the line. Of course, 3rd party homescreens also weren't a possibility then, considerations would've been pretty different...

Given we've stopped targeting very low-end devices, I'd say initial startup time for the homescreen is less of an issue than it used to be. I'd also be pretty surprised if there was anyone in the world that had a FirefoxOS device with a few hundred apps installed - I expect other performance bugs would make that prohibitive long before the startup cost of apps db iteration (I can't imagine edit mode coping with hundreds of apps...)

	Chris Lord [:cwiiis] Assignee
	Comment 53 • 9 years ago

Hey Kevin, just wanted to make sure I didn't misunderstand anything - this is waiting on you trying it out, right? If not, let me know what you'd like me to add and I'll get on it :)

	Kevin Grandon :kgrandon
	Comment 54 • 9 years ago

Comment on attachment 8622412 [details] [review]
Handle defunct apps in verticalhome

I didn't have time to test this out, but the code makes sense to me and it shouldn't harm anything to land it. Thanks!

	Chris Lord [:cwiiis] Assignee
	Comment 55 • 9 years ago

Merged: https://github.com/mozilla-b2g/gaia/commit/fc9cb65bfe557063792e0cf10f7939f03f0532e5

	Doug Sherk (:drs) (inactive)
	Comment 57 • 9 years ago

QA, Naoki, we might want to pull this into Spark RC2. Please verify that this doesn't break anything.

	Pi Wei Cheng [:piwei] (inactive)
	Comment 58 • 9 years ago

Today's nightlies don't contain the fix, so I used inbound builds for testing.

Test results on Flame and Aries: Original bug appears to be fixed - Repro rate is 0/7 on Flame, and 0/3 on Aries. No other issues were found testing around Homescreen app grouping.

Device: Flame (319MB, full flashed, KK)
BuildID: 20150617102851
Gaia: b404c41c5471c31610e64defb74ec066b411e724
Gecko: 428d82117830
Gonk: a4f6f31d1fe213ac935ca8ede7d05e47324101a4
Version: 41.0a1 (3.0 Master) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0

Device: Aries
BuildID: 20150617221811
Gaia: 236a9f6adab172942d5c4dd6ec3427d1b9d83d15
Gecko: d5a624e97666
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 41.0a1 (3.0 Master) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0

---

Reporters of bugs duplicated to this bug are welcome to check this fix; since there are no solid STRs on those duped bugs I wouldn't know if they're indeed fixed.

Leaving verifyme for an actual verification on nightly builds.

	Oliver Nelson [:oliverthor]
	Comment 59 • 9 years ago

Issue is VERIFIED FIXED on 3.0 for flame devices [nightly]
Results: Deleting a Marketplace app and restarting the device causes no issues with homescreen functionality.

Device: Flame 3.0
BuildID: 20150618010201
Gaia: b404c41c5471c31610e64defb74ec066b411e724
Gecko: a3f280b6f8d5
Gonk: a4f6f31d1fe213ac935ca8ede7d05e47324101a4
Version: 41.0a1 (3.0) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0
Repro: 3/3

	Naoki Hirata :nhirata (please use needinfo instead of cc)
	Comment 60 • 9 years ago

Should be in the latest OTAs.