Closed Bug 1035272 Opened 5 years ago Closed 5 years ago

[B2G][Homescreen] Entertainment smart collection icon is not migrated

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:2.0+, b2g-v2.0 verified, b2g-v2.1 verified)

VERIFIED FIXED
2.1 S2 (15aug)
blocking-b2g 2.0+
Tracking Status
b2g-v2.0 --- verified
b2g-v2.1 --- verified

People

(Reporter: astole, Assigned: kgrandon)

References

Details

(Keywords: dataloss, regression, smoketest, Whiteboard: [systemsfe])

Attachments

(4 files)

Attached file logcat
When doing an OTA update the layout is different then when flashing to the latest build. This incorrect update causes the Entertainment smart collection to not display correctly.

Repro Steps:
1) Update a Flame to BuildID: 20140703040209
2) Download and install latest update via OTA

Actual:
The homescreen does not correctly update to the new homescreen layout

Expected:
The device updates to the correct layout via OTA

2.1 Environmental Variables:
Device: Flame 2.1
BuildID: 20140707040201
Gaia: 93daa354671a698634a3dc661c8c9dcb7d824c31
Gecko: 1dc6b294800d
Version: 33.0a1
Firmware Version: v122

Repro frequency: 100%
See attached: Screenshot, logcat
Attached image Screenshot
Attaching screenshot of homescreen with the device flashed and of the device after OTA update.
Note: Logcat is from the download to the installation of the update before the device restarted.

This issue does not occur when updating via OTA on 2.0. The homescreen displays correctly.

Environmental Variables:
Device: Flame 2.0
Build ID: 20140707000200
Gaia: ef67af27dff3130d41a9139d6ae7ed640c34d922
Gecko: f53099796238
Firmware Version: v122

2.0 User agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

2.1 User agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Keywords: smoketest
Discussed with Marcia in IRC, not going to block smoketest on this.

QAWanted to OTA test 1.4 -> 2.1 and 2.0 -> 2.1, the 2.0 testing earlier was 2.0 -> 2.0 which does not have the new homescreen layout.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Keywords: smoketestqawanted
Hi Andrew,

   Could you take a screenshot of the horizontal homescreen before OTA. The vertical homescreen tries to have the same layout that users have in the old home. BTW the entertainment collection has not icon and it seems a bug. If you have the same layout in vertical home than old homescreen, this is the expected behavior. So the bug would be only the missing icon for entertainment collection.

Carmen,

   Could you test it why the collection is not showing the icon?

Thanks a lot

(In reply to Andrew Stole from comment #1)
> Created attachment 8451713 [details]
> Screenshot
> 
> Attaching screenshot of homescreen with the device flashed and of the device
> after OTA update.
Flags: needinfo?(carmen.jimenezcabezas)
Flags: needinfo?(astole)
I think the problem is that we updated the icon layout part way through 2.0. Can you confirm that this bug was reported for an OTA update from a 2.0 build to a recent 2.0 build?

You should check Horizontal -> Vertical migration paths, as we are currently not spending time supporting icon details for 2.0 -> 2.0 updates, this is not something that users would run into.
Whiteboard: [systemsfe]
Attached image Screenshot1
Adding screenshot of the Homescreen before the OTA and clearing needinfo.
Flags: needinfo?(astole)
(In reply to Andrew Stole from comment #6)
> Created attachment 8452348 [details]
> Screenshot1
> 
> Adding screenshot of the Homescreen before the OTA and clearing needinfo.

Can we verify if this was a 2.0 -> 2.0 OTA update, or a 1.4 -> 2.0 OTA update?
Flags: needinfo?(astole)
This issue did not occur on 2.0 -> 2.0, it was only a 2.1 -> 2.1 OTA update.
Flags: needinfo?(astole)
In that case this is happening as expected. We did try to migrate default icon positions for developer OTA updates as we don't have the cycles to support this.

Sorry about the confusion here. Note: for 1.4 -> 2.x migrations we should try to preserve user ordering of icons. For fresh flashes we would have our new icon layout, so you would also see roughly the same thing there.

I'm going to close this as a WONTFIX because the issue is known, but not something that impacts users, and not something that we're going to fix.
Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(carmen.jimenezcabezas)
Resolution: --- → WONTFIX
I think the WONTFIX here is a bit premature. There's two missing pieces not analyzed here:

1. The fact that entertainment is missing an icon post update
2. An analysis of what happens on 2.0 ---> 2.1 & 1.4 ---> 2.1, as those scenarios are plausible to support

Reopening to get more information here.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Holding on a blocking decision until comment 10's questions are answered.
Blocks: 1015336
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking?]
Actually should be marked non-blocking unless this later gets confirmed on 2.0.
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking?] → [VH-FL-blocking-][VH-FC-blocking-]
(In reply to Jason Smith [:jsmith] from comment #10)
> I think the WONTFIX here is a bit premature. There's two missing pieces not
> analyzed here:
> 
> 1. The fact that entertainment is missing an icon post update

Entertainment is missing from the "flashed" version because we've removed it from the default shipping collections.

> 2. An analysis of what happens on 2.0 ---> 2.1 & 1.4 ---> 2.1, as those
> scenarios are plausible to support

In these scenarios we should support migrating the positions of the pages into sections as specified by other bugs.

I still think this should be closed as wontfix because the reported issue is one we're not supporting (the 2.1 -> 2.1 OTA update for new icon positions during the dev cycle)
(In reply to Kevin Grandon :kgrandon from comment #13)
> (In reply to Jason Smith [:jsmith] from comment #10)
> > I think the WONTFIX here is a bit premature. There's two missing pieces not
> > analyzed here:
> > 
> > 1. The fact that entertainment is missing an icon post update
> 
> Entertainment is missing from the "flashed" version because we've removed it
> from the default shipping collections.

Then why does it reappear as a broken icon post update?

> 
> > 2. An analysis of what happens on 2.0 ---> 2.1 & 1.4 ---> 2.1, as those
> > scenarios are plausible to support
> 
> In these scenarios we should support migrating the positions of the pages
> into sections as specified by other bugs.
> 
> I still think this should be closed as wontfix because the reported issue is
> one we're not supporting (the 2.1 -> 2.1 OTA update for new icon positions
> during the dev cycle)

A 2.1 --> 2.1 migration bug means there could be a potential data migration issue from past releases to 2.1, given that past trends of data migration bugs have shown that tends to be the case. I'd like to have this checked before we conclude that this only happens in a 2.1 --> 2.1 migration.
It's only a bug because we changed the layout post 2.1 :) This should not be something a user will run into.

If you want to leave it open to do additional verification on 1.4 -> 2.x migrations that works for me.
QA Contact: ckreinbring
Updating from Flame 1.4 -> Flame 2.1 and Flame 2.0 -> Flame 2.1 shows the homescreen layout that is different from a flashed version of the build, including the Everything.me Entertainment category icon as the default rocket icon.

1.4 -> 2.1
From:
Build ID: 20140703000230
Gaia: f250750c9b8381560fa33b2383737736e4dbdff5
Gecko: 4c05c3fb440d
Platform Version: 30.0
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

To:
Build ID: 20140710071928
Gaia: 09642e74e250fbc62db860c808ef188628fca55d
Gecko: f93c0ef45597
Platform Version: 33.0a1
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0


2.0 -> 2.1
From:
Build ID: 20140703000248
Gaia: 7ad00b0bd84d5d97e0801e3b3ceaac33fcd90e05
Gecko: e87f7b398fce
Platform Version: 32.0a2
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

To:
Build ID: 20140710071928
Gaia: 09642e74e250fbc62db860c808ef188628fca55d
Gecko: f93c0ef45597
Platform Version: 33.0a1
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking-] → [VH-FL-blocking-][VH-FC-blocking-][QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking-][QAnalyst-Triage?] → [VH-FL-blocking-][VH-FC-blocking-][QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
comment 16 implies this happens in realistic data migration use cases to 2.1, so this is a data loss issue we need to fix.
blocking-b2g: --- → 2.1?
Keywords: dataloss, regression
I was able to reproduce the issue where the entertainment icon is a rocketship migrating from Flame 1.4 to 2.0, moving nom for 2.0 respectively.

From:
Environmental Variables:
Device: Flame 1.4
Build ID: 20140710000202
Gaia: b0e9b4bdb39c5eb93a6783a34624ffc84f62b126
Gecko: ccabaf8826a4
Version: 30.0 (1.4)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0


To: 
Environmental Variables:
Device: Flame 2.0
Build ID: 20140710134018
Gaia: 1bd6e8957ccf310b2f75ba5695b058a2e284df3a
Gecko: f0e91a6bfd1b
Version: 32.0a2 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
blocking-b2g: 2.1? → 2.0?
blocking-b2g: 2.0? → 2.0+
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking-][QAnalyst-Triage+] → [VH-FL-blocking-][VH-FC-blocking+][QAnalyst-Triage+]
Renaming this bug as it sounds like the bug that we are tracking is the actual loss of an icon. We go from having one to the default rocketship icon, and not a layout problem. Over an OTA update, we should maintain your collections, and the icons. In this case it sounds like we're not using the proper icons for migrated smart collections.
Summary: [B2G][Homescreen]OTA does not update correctly to new homescreen layout → [B2G][Homescreen] Smart collection icon is not migrated
Duplicate of this bug: 1037183
Cristian - if you get a chance could you take a quick look at this blocker? If you don't get to it I can try to pick it up during my day tomorrow. Thanks!
Flags: needinfo?(crdlc)
Hi Kevin, Carmen told me yesterday that she is investigating this bug so I assign it to her. Carmen, if you have some problem with it please remove the "Assigned To" field and comment what you want here. Thanks Carmen
Assignee: nobody → carmen.jimenezcabezas
Flags: needinfo?(crdlc) → needinfo?(carmen.jimenezcabezas)
Carmen, could we only do the migration when the OTA is from 1.x -> 2.0 instead of 2.0 -> 2.1. If we are in 2.0 we don't have to migrate anything from old homescreen. Maybe is it working in this way?
Target Milestone: --- → 2.0 S6 (18july)
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking+][QAnalyst-Triage+] → [VH-FL-blocking-][VH-FC-blocking+][QAnalyst-Triage+][lead-review+]
The problem happens only with migrated smart collection that wasn't a predefined one.
The associated icon is loaded from the app collection (for example, app://collection.gaiamobile.org/collections/showbiz/icon.png). Since this collection is not one of the predefined ones, it isn't included on the app collections and so it can't find it
I'll upload a patch to fix this.
Flags: needinfo?(carmen.jimenezcabezas)
Whiteboard: [systemsfe] → [systemsfe][ETA=7/19]
Good catch, thanks a lot Carmen, excellent job!! So alternatives:

1) To have all the icons [1] in the collection package in build time (not only predefined by OEMs or operators)

2) To point to app://homescreen.gaiamobile.org/collections/showbiz/icon.png instead of app://collection.gaiamobile.org/collections/showbiz/icon.png

3) To save blobs...

With the first one we could show the new icons designed for 2.0 but with the rest of approaches we had the legacy icon thought

[1] https://github.com/mozilla-b2g/gaia/tree/master/apps/collection/collections

Thoughts?


(In reply to Carmen Jimenez Cabezas from comment #24)
> The problem happens only with migrated smart collection that wasn't a
> predefined one.
> The associated icon is loaded from the app collection (for example,
> app://collection.gaiamobile.org/collections/showbiz/icon.png). Since this
> collection is not one of the predefined ones, it isn't included on the app
> collections and so it can't find it
> I'll upload a patch to fix this.
Flags: needinfo?(kgrandon)
Flags: needinfo?(carmen.jimenezcabezas)
Flags: needinfo?(amirn)
IMO the only possible option is number 3:
- We can't have icons for custom collections.
- If the user re-arranged a Collection, the predefined icon is no longer valid
Flags: needinfo?(amirn)
AFAIR the custom collection icons are "data:image/png;base64...." so we don't have problems with them. Are you suggesting that if we migrate for example "Music" from 1.x to 2.0 we should use the icon in 1.x instead of the new one?

(In reply to Amir Nissim (:amirn) from comment #26)
> IMO the only possible option is number 3:
> - We can't have icons for custom collections.
> - If the user re-arranged a Collection, the predefined icon is no longer
> valid
Maybe I didn't understand correctly, but according to Carmen:
> The problem happens only with migrated smart collection that wasn't a predefined one.

You're right about the dataURI icons though...

So this happens *only* for pre-installed Collections?
Can we reproduce to any other Collections except for Entertainment?

Maybe the problem is that "Entertainment" was renamed to "Showbiz"? (bug 944056)
This might also explain the par between v1.3 and v1.4...
If we can use the new icon background I think that would be ideal, otherwise the icon will probably refresh and look totally different on the next state. 

My preference would honestly be to show some default placeholder and then queue the icon to refresh on the next time the device connects to the internet. Trying to migrate the icon will not look good as we display them in a larger size - maybe that is acceptable for 2.0 though?
Just saw Amir's comment. If it's only a problem with that one collection - I'm fine with a dirty hack somewhere to update the path to some hardcoded value.
Flags: needinfo?(kgrandon)
If I understand properly the problem is:

Music in 1.3 is app://homescreen.gaiamobile.org/collections/music/icon.png

After migrating we save as icon for 2.0

app://collection.gaiamobile.org/collections/music/icon.png

If the OEM added "music" as a predefined collection the icon is there because it was copied at build time. But if this collection was not selected for the OEM as predefined collection, this path app://collection.gaiamobile.org/collections/music does not exist (AFAIK only predefined collections are copied at build time, because of this, I thought that why not to copy the ten collections at build time, this is just 10 icons and a manifest file thought)

Amir, for sure, the Showbiz hurts us :) We should rename it in the migration process.
+1 for Kevin's suggestion for temporary placeholder

Crisitian, if that's the problem, can't we do
"app://homescreen.gaiamobile.org/collections/music/icon.png".replace('homescreen', 'collection')

in the migration process?
Summarizing, my approach will be:

1) Copy all collections in the collection app package at build time (they are 10 collections, it means 10 icons and 10 manifest files). Not only pre-installed.

https://github.com/mozilla-b2g/gaia/tree/master/apps/collection/collections

2) Map app://homescreen.gaiamobile.org/collections/xxx/icon.png to app://collections.gaiamobile.org/collections/xxx/icon.png as we do right now

3) Rename entertainment to showbiz (are there any other change?)

BTW, Carmen could say us what is the easier
After speaking with our product guys, we don't think this is a bug at all. This only happens if a collection that was present on 1.X is not present on 2.X on a FOTA. And that will not happen, according to our product guys. So this is not something users will ever see.

In any case, and if you don't mind builds being sligthly bigger, the easiest solution is indeed to just create the builds with all the collections and not just the selected ones (and still have care of not erasing any on the codebase!). We cannot store the blob of the icon because by the time Gaia boots the icon doesn't exist anymore (since the app is overwritten by the FOTA process).
Flags: needinfo?(carmen.jimenezcabezas)
See Also: → 1037556
Closing as invalid because according to our product guys this is something that will not happen on any release or update path. Please reopen if you think otherwise.
Status: REOPENED → RESOLVED
Closed: 5 years ago5 years ago
Resolution: --- → INVALID
So apparently this is still happening on a 1.3 -> 2.0 update. Seems like it is a *bug* that should be fixed, but we should decide whether or not a user can run into it.

I'm reopening this for investigation/clarification, but we should not block until we clarify if a user can hit it. We may also want to fix this for our internal testing, but if we don't get this into 2.0 then I'm not sure if it makes sense.
Status: RESOLVED → REOPENED
blocking-b2g: 2.0+ → ---
Resolution: INVALID → ---
Summary: [B2G][Homescreen] Smart collection icon is not migrated → [B2G][Homescreen] Entertainment smart collection icon is not migrated
[Blocking Requested - why for this release]:(In reply to Kevin Grandon :kgrandon from comment #36)
> So apparently this is still happening on a 1.3 -> 2.0 update. Seems like it
> is a *bug* that should be fixed, but we should decide whether or not a user
> can run into it.
> 
> I'm reopening this for investigation/clarification, but we should not block
> until we clarify if a user can hit it. We may also want to fix this for our
> internal testing, but if we don't get this into 2.0 then I'm not sure if it
> makes sense.

This is showing up in our smoketest of 1.3 --> 2.0 migration, so I definitely think this is possible for someone to hit, especially since 1.3 --> 2.0 update path is supported.
blocking-b2g: --- → 2.0?
(In reply to Jason Smith [:jsmith] from comment #37)
> This is showing up in our smoketest of 1.3 --> 2.0 migration, so I
> definitely think this is possible for someone to hit, especially since 1.3
> --> 2.0 update path is supported.

Will users hit OTA updates though, or only FOTA?
(In reply to Kevin Grandon :kgrandon from comment #38)
> (In reply to Jason Smith [:jsmith] from comment #37)
> > This is showing up in our smoketest of 1.3 --> 2.0 migration, so I
> > definitely think this is possible for someone to hit, especially since 1.3
> > --> 2.0 update path is supported.
> 
> Will users hit OTA updates though, or only FOTA?

FOTA primarily. However, this involves data migration, which is independent of the system update workflow to my understanding.
Sure, I am just going by what comment 34 and comment 35 said. I think in this case the upgrade payloads may be different in what gets delivered to the phone.
Blocking+, b/c regression, dataloss, etc.
blocking-b2g: 2.0? → 2.0+
(In reply to Dietrich Ayala (:dietrich) from comment #41)
> Blocking+, b/c regression, dataloss, etc.

We haven't confirmed that this is the case yet, and I think we need information on this first. Carmen states this in comment 34/35.

Carmen - could you weigh in if this is truly a data-loss case? You mentioned that "So this is not something users will ever see". We need to understand why we see it over OTA, but not FOTA updates - can you help clarify? Thanks!
blocking-b2g: 2.0+ → 2.0?
Flags: needinfo?(carmen.jimenezcabezas)
(In reply to Carmen Jimenez Cabezas  PTO 18th Aug - 5th Sep from comment #34)
> This only happens if a collection that was present on 1.X is not present on 2.X on a FOTA. 

By default, in 1.x we have 4 collections by default, but each partner can customize that in any way they want.
In 2.x, we have 3 of those 4 collections by default, but again, each partner can customize.

I suspect that while not all partners will hit this (if they are aware and configure the update to avoid it), that some may, causing an issue for those users.

It sounds like we don't have the proper environment to test FOTA for this scenario (based on what jsmith tells me).  Let's certainly see what Carmen has to say, but we may need to block on this to be safe.
Attached file Github pull request
One way that we can solve this is to copy over the showbiz icon regardless of whether it's in the grid or not. Then we try to access it after an OTA or FOTA update it should just work. The fix is relatively low risk, and just includes an additional asset in the profile.

Stealing the bug and flagging a few people for review.

(In reply to Peter Dolanjski [:pdol] from comment #43)
> but we may need to block on this to be safe.

Alright, that works for me. This patch turned out to be fairly low risk after all so I don't really have any problems putting it into 2.0.
Assignee: carmen.jimenezcabezas → kgrandon
Status: REOPENED → ASSIGNED
Attachment #8472599 - Flags: review?(yurenju.mozilla)
Attachment #8472599 - Flags: review?(carmen.jimenezcabezas)
Attachment #8472599 - Flags: review?(amirn)
Flags: needinfo?(carmen.jimenezcabezas)
Comment on attachment 8472599 [details] [review]
Github pull request

this is a low risk commit so r=yurenju and I would love to know if we have long term solution for similar scenario since it looks easily happen again.
Attachment #8472599 - Flags: review?(yurenju.mozilla) → review+
blocking-b2g: 2.0? → 2.0+
Comment on attachment 8472599 [details] [review]
Github pull request

Thanks Yuren. I'm going to land with r=yuren, but feel free to chime in if you have any details.
Attachment #8472599 - Flags: review?(carmen.jimenezcabezas)
Attachment #8472599 - Flags: review?(amirn)
Master: https://github.com/mozilla-b2g/gaia/commit/81683ce5bf9305148c335fa810bb979941cccb22
Status: ASSIGNED → RESOLVED
Closed: 5 years ago5 years ago
Resolution: --- → FIXED
Please note that this patch only fixes this for the specific case of this collection (Showbiz or Entertainment).
Users might still run into this problem if the OEM/integrator/operator that creates the build erases any other collection from one build to the other. 
But, as I said previously, in our concrete case this is a non issue.
v2.0: https://github.com/mozilla-b2g/gaia/commit/499a1d2551e5a2c98b984a1e74b064d034b9d4c1
Whiteboard: [systemsfe][ETA=7/19] → [systemsfe]
Target Milestone: 2.0 S6 (18july) → 2.1 S2 (15aug)
I can no longer reproduce this issue on the latest 2.0 Flame build:

Enviromental Variables:
-----------------------
Device: Flame 2.0
BuildID: 20140815000200
Gaia: 295c7f50707372e5af6d8e83148d2d970076dfd6
Gecko: 879c5208084f
Version: 32.0 (2.0)
Firmware: v123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Entertainment smart collection icon is properly migrated after OTA.
Status: RESOLVED → VERIFIED
Verified fixed on Flame 2.1 KK (319mb/full flash) 

Actual result: Homescreen from OTA matches homescreen from flash

Device: Flame 2.1
BuildID: 20141021001201
Gaia: e458f5804c0851eb4e93c9eb143fe044988cecda
Gecko: ee86921a986f
Gonk: 05aa7b98d3f891b334031dc710d48d0d6b82ec1d
Version: 34.0 (2.1)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking+][QAnalyst-Triage+][lead-review+] → [VH-FL-blocking-][VH-FC-blocking+][QAnalyst-Triage?][lead-review+]
Flags: needinfo?(pbylenga)
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking+][QAnalyst-Triage?][lead-review+] → [VH-FL-blocking-][VH-FC-blocking+][QAnalyst-Triage+][lead-review+]
Flags: needinfo?(pbylenga)
You need to log in before you can comment on or make changes to this bug.