Steps to reproduce 1. Flash your device to the last 1.4 nightly build. 1bis. (Workaround) Change the channel to aurora with that script https://github.com/nhirata/B2G-flash-tool/blob/new_channels/change_channel.sh 2. Install a hosted app (like Facebook) via Marketplace 4. Upgrade via OTA Actual result Default icon is displayed for hosted apps until a data connection is established. See attached screenshot for details. Additional notes Update channel have recently changed. The script in step 1bis has been modified to handle that change.

Standard user path.

QA Wanted to know if this reproduces with 1.3 --> 1.4.

Wouldn't the user have an internet connection in the first place due to performing an OTA update? Also I don't think this is doable in the first place. The vertical homescreen now uses different icon sizes than the horizontal homescreen, so we wouldn't have the proper icon cached. We need to fetch it before we can display it.

Yes, but the Internet connection can be interrupted while uncompressing or installing the new package. Also a data connection is not immediately guaranteed after a phone restart. Let's see if this issue reproduces with 1.3 -> 1.4, when the Internet connection is turned off before installing the OTA update.

Sure, but it's still impossible to have a perfect solution as the icons that we have in the cache are the wrong size. We can potentially spend a lot of time working on something for a placeholder icon, but I would recommend not blocking on this.

Can we scale the existing one until we fetch the new one with the right size? Or show some other sharp placeholder icon that indicates that we are waiting for data from the internet? There is no perfect solution and we need a workaround here.

(In reply to Gregor Wagner [:gwagner] from comment #6) > Can we scale the existing one until we fetch the new one with the right > size? Or show some other sharp placeholder icon that indicates that we are > waiting for data from the internet? > There is no perfect solution and we need a workaround here. I feel like the default icon should accomplish that, and if it's not good enough, we should probably come up with a new icon and only use the default when we can't load the normal icon for some reason (site down/download canceled). ni? on firefoxos-ux to see if there is a preference here.

Flagging Peter and Amy on this.

Hey guys, My two cents: I don't think the scaling up of existing low-res icons is a going to look good, which would only leave us with the option of using a placeholder. So it's a matter of what should the placeholder be? We could try something that communicates that you aren't connected, or that you need to connect. But that might be overkill. The default app icon used here isn't too bad of a fallback. I'll chat with my team tomorrow to see if we can think of a better solution here.

Hey Kevin/guys, I just talked to Patryk, and he thinks we should scale up the existing lower-res icon until the user gets connectivity. If it's fairly low-effort, can we try that and see if it looks shippable?

(In reply to Peter La from comment #10) > Hey Kevin/guys, > > I just talked to Patryk, and he thinks we should scale up the existing > lower-res icon until the user gets connectivity. If it's fairly low-effort, > can we try that and see if it looks shippable? Actually this is a ton of work =/ This is such a small use-case that I don't think we should invest this much time and code into it when we could be polishing other parts. We can possibly investigate next week though if you feel strongly about it.

Data migration is not a part of feature landing. Investigate later sounds like a plan to me.

If this issue is not reproducible from 1.3 to 1.4 of course.

(In reply to Stephany Wilkes from comment #8) > Flagging Peter and Amy on this.

Yeah, that's fine Kevin. Using the default app icon for now works for me. There are probably a bunch of other things that would be higher than this in the polish phase as well. It would be good to get a better understanding of how often this would happen, and for how long before the user connects.

Based on comment 15, moving to v.homescreen.next while we work on bigger fish. Marking as FC? but I don't think we should block there either, unless we magically get a lot of extra time..

Mass update: Resolve wontfix all issues with legacy homescreens. As of 2.6 we have a new homescreen and having these issues open is confusing. All issues will block bug 1231115 so we can use that to re-visit any of these if needed.