Update obsolete settings to current settings.

NEW
Unassigned

Status

Firefox OS
General
2 years ago
2 years ago

People

(Reporter: nhirata, Unassigned)

Tracking

({foxfood})

unspecified
ARM
Gonk (Firefox OS)
foxfood

Firefox Tracking Flags

(tracking-b2g:backlog)

Details

With the recent of issues with OTA and also dogfood, people have been backing up and restoring.

We need a way for the user to force the system to check if there's an obsolete preference and correct it to the appropriate pref.

Example of the issue:see bug 1144557
Hey Michael?  I know you backup and restore your profile, I thought you might be interested in this bug and possibly help find someone to work on this?
Flags: needinfo?(mhenretty)

Comment 2

2 years ago
I will add that the problem occurs when flashing and then restoring too (I noticed it in the mentioned bug after backing up with QA tools, full flashing for the new base image, then update and restored).

For this specific preference, not only that the value was obsolete: the value was just absent.
So I guess it would be useful to check for missing preferences and for supplementary ones.
Keywords: foxfood
I think this needs to be done on a case by case basis. When we change the name of pref's and obsolete them, it if up to the developer to either fix the upgrade code or support the old pref (and change it to the new schema when it's detected). If they don't do that properly, there is not a whole lot we can do from the system level to blanket fix old prefs.
Component: Gaia::System → General
Flags: needinfo?(mhenretty)

Comment 4

2 years ago
(In reply to Michael Henretty [:mhenretty] from comment #3)
> I think this needs to be done on a case by case basis. When we change the
> name of pref's and obsolete them, it if up to the developer to either fix
> the upgrade code or support the old pref (and change it to the new schema
> when it's detected). If they don't do that properly, there is not a whole
> lot we can do from the system level to blanket fix old prefs.

No way to have like a standard scheme, and do a comparison between it and the current prefs state?
This way, you compare keys and remove unnecessary ones, add missing ones. that would be a good first step like for this totally missing pref.
After that, if it was possible to check possible values or not, it would be better, but that would just be after and an improvement to the first part.
Flags: needinfo?(mhenretty)
Summary: Update obsolete preferences to current preferences. → Update obsolete settings to current settings.
(In reply to Clément Lefèvre from comment #4)
> No way to have like a standard scheme, and do a comparison between it and
> the current prefs state?
> This way, you compare keys and remove unnecessary ones, add missing ones.
> that would be a good first step like for this totally missing pref.
> After that, if it was possible to check possible values or not, it would be
> better, but that would just be after and an improvement to the first part.

I believe we currently do that for the missing ones (ie. we should have a default value). Removing unnecessary ones might be trickier. I agree this is a source of bugs, but I'm not sure the best solution.
Flags: needinfo?(mhenretty)

Comment 6

2 years ago
(In reply to Michael Henretty [:mhenretty] from comment #5)
> (In reply to Clément Lefèvre from comment #4)
> > No way to have like a standard scheme, and do a comparison between it and
> > the current prefs state?
> > This way, you compare keys and remove unnecessary ones, add missing ones.
> > that would be a good first step like for this totally missing pref.
> > After that, if it was possible to check possible values or not, it would be
> > better, but that would just be after and an improvement to the first part.
> 
> I believe we currently do that for the missing ones (ie. we should have a
> default value). Removing unnecessary ones might be trickier. I agree this is
> a source of bugs, but I'm not sure the best solution.

It looks like there is nothing for missing ones, as you can see in comments 60 to 63 from the bug Naoki pointed out, especially in this particular comment: https://bugzilla.mozilla.org/show_bug.cgi?id=1144557#c61

The setting "appsearch.url" was really missing on my phone, and not here at all.
I just tried right now a shallowflash without restoring my profile, and the setting was not here either.

I didn't tested after a full flash as I would prefer to avoid to, but I can do it if needed for some tests.
Flags: needinfo?(mhenretty)
Well, the developer is supposed to provide a default value when they read it (see for example [1]). But perhaps you are suggesting on every boot we read the entire settings database and add ones we don't have in common-settings [2] and deleting unrecognized ones. This would be doable, but it might have negative performance impact. Conversely, we version our settings DB and run upgrade logic on it when we detect an out of date version. This would be more performant at the expense of code complexity. I'm not sure what the best approach here would be.

1.) https://github.com/mozilla-b2g/gaia/blob/master/shared/js/settings_helper.js#L19
2.) https://github.com/mozilla-b2g/gaia/blob/master/build/config/common-settings.json
Flags: needinfo?(mhenretty)

Comment 8

2 years ago
(In reply to Michael Henretty [:mhenretty] from comment #7)
> Well, the developer is supposed to provide a default value when they read it
> (see for example [1]). But perhaps you are suggesting on every boot we read
> the entire settings database and add ones we don't have in common-settings
> [2] and deleting unrecognized ones. This would be doable, but it might have
> negative performance impact. Conversely, we version our settings DB and run
> upgrade logic on it when we detect an out of date version. This would be
> more performant at the expense of code complexity. I'm not sure what the
> best approach here would be.
> 
> 1.)
> https://github.com/mozilla-b2g/gaia/blob/master/shared/js/settings_helper.
> js#L19
> 2.)
> https://github.com/mozilla-b2g/gaia/blob/master/build/config/common-settings.
> json

Maybe a third approach, which wouldn't work in every case, but would cover most of them: include these checks in backup and restore profiles scripts. For sure it will not cover cases of permanent OTA, but if this process of checking in included in those updates would it be enough?

Probably is it a bit more difficult to implement, but performance impact would not be important in such cases I guess as it would only trigger checks during upgrades (which would become slightly slower) and profile restores.

I need to add that I sadly have no idea of how feasible is it.
Flags: needinfo?(mhenretty)
(In reply to Clément Lefèvre from comment #8)
> (In reply to Michael Henretty [:mhenretty] from comment #7)
> > Well, the developer is supposed to provide a default value when they read it
> > (see for example [1]). But perhaps you are suggesting on every boot we read
> > the entire settings database and add ones we don't have in common-settings
> > [2] and deleting unrecognized ones. This would be doable, but it might have
> > negative performance impact. Conversely, we version our settings DB and run
> > upgrade logic on it when we detect an out of date version. This would be
> > more performant at the expense of code complexity. I'm not sure what the
> > best approach here would be.
> > 
> > 1.)
> > https://github.com/mozilla-b2g/gaia/blob/master/shared/js/settings_helper.
> > js#L19
> > 2.)
> > https://github.com/mozilla-b2g/gaia/blob/master/build/config/common-settings.
> > json
> 
> Maybe a third approach, which wouldn't work in every case, but would cover
> most of them: include these checks in backup and restore profiles scripts.
> For sure it will not cover cases of permanent OTA, but if this process of
> checking in included in those updates would it be enough?
> 
> Probably is it a bit more difficult to implement, but performance impact
> would not be important in such cases I guess as it would only trigger checks
> during upgrades (which would become slightly slower) and profile restores.

This is a good idea, the only thing is that it would require the flashing tools to know about the schema of the settings DB. Not impossible though, and it does alleviate the perf concerns.
Flags: needinfo?(mhenretty)
QA Whiteboard: [foxfood-triage]

Updated

2 years ago
Blocks: 1192705

Comment 10

2 years ago
[Tracking Requested - why for this release]:
No longer blocks: 1192705
tracking-b2g: --- → backlog
You need to log in before you can comment on or make changes to this bug.