Closed Bug 1026733 Opened 5 years ago Closed 4 years ago

[1.4 => 2.0][Vertical Homescreen] Icons of hosted apps are missing after OTA update until an Internet connection is established

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: jlorenzo, Unassigned)

References

Details

(Whiteboard: [systemsfe])

Attachments

(1 file)

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.
blocking-b2g: --- → 2.0?
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking+]
See Also: → 1017069
QA Wanted to know if this reproduces with 1.3 --> 1.4.
Keywords: qawanted
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.
Flags: needinfo?(firefoxos-ux-bugzilla)
Flagging Peter and Amy on this.
Flags: needinfo?(pla)
Flags: needinfo?(firefoxos-ux-bugzilla)
Flags: needinfo?(amlee)
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?
Flags: needinfo?(pla)
(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.
Flags: needinfo?(amlee)
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..
Blocks: vertical-home-next
No longer blocks: 1015336
blocking-b2g: 2.0? → ---
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking+] → [VH-FL-blocking-][VH-FC-blocking?]
Keywords: qawanted
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking?] → [VH-FL-blocking-][VH-FC-blocking-]
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.
Blocks: 1231115
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.