944290 - [OTA][Data Migration][keyboard] The added keyboards layouts will be lost after update from v1.1 to v1.2

Status: RESOLVED DUPLICATE of bug 888253

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

Description

[Hubert Lu[:hlu] <[e-mail]>]

Attachment: logcat.txt

* Build Information
Gaia:     92cd11ea023dd6598d82d859ae3c945ff6589ce6
Gecko:    http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/14e91ab12441
BuildID   20131127004001
Version   26.0
ro.build.version.incremental=eng.cltbld.20131127.073824


* Reproduce Steps
1. Flash device to v1.1 build from PVT
2. Change update URL to http://update.boot2gecko.org/unagi/1.2.0/nightly/update_20131127004001.xml
3. Go to settings -> Keyboard under Personalization
4. Select mutiple language keyboard layout. (English, Espanol, Francais, Deutsch..)
5. Download the update package and install the update.

* Actual results:
1. Only the default keyboard layout is selected (English) after update

* Expected result:
1. All of selected keyboard layout should be kept after update.

Comment 1

[Askeing Yen[:askeing][:fyen]]

Hi Rudy, could you please help to take a look? Thank you :)

Comment 2

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

This is because we changed the format to store keyboard related settings.
For v1.1, it is a list,
 "keyboard.layouts.english": true,
 "keyboard.layouts.french": true,
 ... 

While starting from v1.2, it is a totally different structure built to store the related info for the new keyboard framework.

--
Actually, we went through a similar data migration issue from v1.0.1 to v1.1, and that was left unresolved.
I am not sure if we should block on this.

Comment 3

[Jason Smith [:jsmith]]

(In reply to Rudy Lu [:rudyl] from comment #2)
> This is because we changed the format to store keyboard related settings.
> For v1.1, it is a list,
>  "keyboard.layouts.english": true,
>  "keyboard.layouts.french": true,
>  ... 
> 
> While starting from v1.2, it is a totally different structure built to store
> the related info for the new keyboard framework.
> 
> --
> Actually, we went through a similar data migration issue from v1.0.1 to
> v1.1, and that was left unresolved.
> I am not sure if we should block on this.

I don't think that's acceptable to ever tolerate data loss in OTA updates. You need a migration path for any data involved in the product. This is a blocker.

Comment 4

[Preeti Raghunath(:Preeti)]

Rudy,

Per discussion with product this is a blocker. Please review further and own the same.

Comment 5

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Will send a patch for this issue.
Thanks.

Comment 6

[:gerard-majax]

It has already been filed under bug 888253 a while ago ...

Comment 7

[Jason Smith [:jsmith]]

(In reply to Alexandre LISSY :gerard-majax from comment #6)
> It has already been filed under bug 888253 a while ago ...

That should have been a blocker. We break all triage rules for FOTA update quality, as this is really easy way to get numerous support complaints easily.

So are you saying this is a dupe then?

Comment 8

[:gerard-majax]

(In reply to Jason Smith [:jsmith] from comment #7)
> (In reply to Alexandre LISSY :gerard-majax from comment #6)
> > It has already been filed under bug 888253 a while ago ...
> 
> That should have been a blocker. We break all triage rules for FOTA update
> quality, as this is really easy way to get numerous support complaints
> easily.
> 
> So are you saying this is a dupe then?

I clearly think it's a dupe, I'm just sad because it has been reported for weeks and this has been considered as a non blocker for koi, and now we have it under the present bug as a koi+ in the rush :(

Comment 9

[Jason Smith [:jsmith]]

Okay - I'll dupe & koi+ bug 888253 & move over relevant flags.