Closed Bug 1154055 Opened 5 years ago Closed 5 years ago

[Homescreen] Deleting a Marketplace app causes broken homescreen UI and functionality after device restart.

Categories

(Firefox OS Graveyard :: Gaia::Homescreen, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:2.5+, b2g-v2.2 unaffected, b2g-master verified)

VERIFIED FIXED
FxOS-S1 (26Jun)
blocking-b2g 2.5+
Tracking Status
b2g-v2.2 --- unaffected
b2g-master --- verified

People

(Reporter: Marty, Assigned: cwiiis)

References

()

Details

(Keywords: regression, Whiteboard: [3.0-Daily-Testing][systemsfe])

Attachments

(4 files)

Attached file logcat-homescreen.txt
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)
Attached image Edit Mode Header.png
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
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
[Blocking Requested - why for this release]:
Severe functional regression of a core feature.

Requesting a window.
blocking-b2g: --- → 3.0?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Whiteboard: [3.0-Daily-Testing] → [3.0-Daily-Testing][systemsfe]
QA Contact: ktucker
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.
QA Contact: ktucker → bzumwalt
QA Contact: bzumwalt
Wil, any changes on the marketplace side that may be causing this ?
Flags: needinfo?(wclouser)
(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?
blocking-b2g: 3.0? → 3.0+
Flags: needinfo?(anygregor)
(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.
Flags: needinfo?(wclouser)
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
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Flags: needinfo?(nhirata.bugzilla)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
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
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
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?
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.
Is this still an issue?
Flags: needinfo?(anygregor)
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
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
Kevin, can you take this one?
Flags: needinfo?(kgrandon)
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...
I doubt this would be the cause, I filed bug 1156683
Flags: needinfo?(nhirata.bugzilla)
Flags: needinfo?(nhirata.bugzilla)
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}]
Flags: needinfo?(kgrandon)
Keywords: qawanted
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}]
Flags: needinfo?(nhirata.bugzilla)
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.
(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?
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.
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...
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 )
Flags: needinfo?(kgrandon)
Sounds like this should possibly be in the gecko Dom webapps component then?
Flags: needinfo?(kgrandon)
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
Flags: needinfo?(kgrandon)
(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.
Flags: needinfo?(kgrandon)
(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.
Flags: needinfo?(nhirata.bugzilla)
Kevin, can you reproduce and help out?
Flags: needinfo?(kgrandon)
(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.
Flags: needinfo?(kgrandon)
Bhavana, this should block Spark.
Flags: needinfo?(bbajaj)
[Blocking Requested - why for this release]:
Nominating to block spark based on Comment 33.
blocking-b2g: 3.0+ → spark?
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.
blocking-b2g: spark? → spark+
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
Flags: needinfo?(bbajaj)
Removing qawanted per comment 36.  If you want more work let us know and add the tag again.
Flags: needinfo?(ktucker)
Keywords: qawanted
Flags: needinfo?(ktucker)
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.
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 )
Flags: needinfo?(nhirata.bugzilla)
I'm seeing this on my dogfood device. Let me know if can help with the bisect process.
Gregor, could you help us find someone to look at this?
Flags: needinfo?(anygregor)
Flags: needinfo?(nhirata.bugzilla)
Chris can take a look.
Flags: needinfo?(anygregor) → needinfo?(chrislord.net)
Duplicate of this bug: 1171025
Duplicate of this bug: 1172692
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.
Assignee: nobody → chrislord.net
Status: NEW → ASSIGNED
Flags: needinfo?(chrislord.net)
Duplicate of this bug: 1173762
Duplicate of this bug: 1173767
It's my top priority to fix this on Monday, seems spark changes are causing this bug to be hit a lot now.
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.
Attachment #8622412 - Flags: review?(kgrandon)
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.
Attachment #8622412 - Flags: feedback+
> 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.
(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...)
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 :)
Flags: needinfo?(kgrandon)
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!
Flags: needinfo?(kgrandon)
Attachment #8622412 - Flags: review?(kgrandon) → review+
Merged: https://github.com/mozilla-b2g/gaia/commit/fc9cb65bfe557063792e0cf10f7939f03f0532e5
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Duplicate of this bug: 1175281
QA, Naoki, we might want to pull this into Spark RC2. Please verify that this doesn't break anything.
QA Contact: pcheng
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.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: qaurgent, qawanted
QA Contact: pcheng
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
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
Status: RESOLVED → VERIFIED
Keywords: verifyme
blocking-b2g: spark+ → 2.5+
Target Milestone: --- → FxOS-S1 (26Jun)
Should be in the latest OTAs.
Flags: needinfo?(nhirata.bugzilla)
You need to log in before you can comment on or make changes to this bug.