Hubert Lu[:hlu] <hlu@mozilla.com> Reporter
	Description • 11 years ago

* 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.

	Askeing Yen[:askeing][:fyen]
	Comment 1 • 11 years ago

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

	Rudy Lu [:rudyl] (inactive after 2015/7/3) Assignee
	Comment 2 • 11 years ago

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.

	Jason Smith [:jsmith]
	Comment 3 • 11 years ago

(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.

	Preeti Raghunath(:Preeti)
	Comment 4 • 11 years ago

Rudy,

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

	Rudy Lu [:rudyl] (inactive after 2015/7/3) Assignee
	Comment 5 • 11 years ago

Will send a patch for this issue.
Thanks.

	:gerard-majax [PTO 01/08/2023-10/09/2023]
	Comment 6 • 11 years ago

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

	Jason Smith [:jsmith]
	Comment 7 • 11 years ago

(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?

	:gerard-majax [PTO 01/08/2023-10/09/2023]
	Comment 8 • 11 years ago

(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 :(

	Jason Smith [:jsmith]
	Comment 9 • 11 years ago

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