1678957 - Preference syncing doesn't work well when distributions/operating systems have different default values for preferences

Status: RESOLVED DUPLICATE of bug 1731249

(Firefox :: Sync, defect, P3)

Description

[Mic Sparrow]

User Agent: Mozilla/5.0 (Linux; Android 10; Nokia 8 Sirocco) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Mobile Safari/537.36

Steps to reproduce:

I am using Firefox on two machines - Lubuntu (Linux) 32 bit and Windows 10 64 bit.
Sync feature is enabled on both.
When the sync setting "sync options/preferences" is marked some issues (listed below) happen.

Actual results:

After each 10 minute synchronization cycle on both devices the following things happen:

• on Linux my DRM settings to play/use DRM turns off. I can manually reanable it but every next sync resets my setting.
• on Windows 10 the highlights section on the new tab page disappeares.

Expected results:

The DRM settings should be enabled on both devices as the options are synced through my Firefox account.
The same thing should happen to the highlights section on the new tab page - also turned on by default and synced.

Comment 1

[Mic Sparrow]

Sorry - forgot to add that Lubuntu uses latest Firefox beta while Firefox on Windows 10 is a Nightly version.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 3

[Mark Hammond [:markh] [:mhammond]]

Sorry you are having this issue - that's very odd. The DRM setting is controlled via the media.eme.enabled preference, which defaults to true, while the "highlights" feature is controlled via browser.newtabpage.activity-stream.feeds.section.highlights. It would be great if you could follow the instructions at https://wiki.mozilla.org/CloudServices/Sync/File_a_desktop_bug, then reproduce the bug, then attach the your log files. the about:sync addon will also help show you the "preferences" collection, so reporting what those 2 preference are in that collection, vs what they are on the PC itself would also be helpful.

Comment 4

[Mic Sparrow]

(In reply to Mark Hammond [:markh] [:mhammond] from comment #3)

Sorry you are having this issue - that's very odd. The DRM setting is controlled via the media.eme.enabled preference, which defaults to true, while the "highlights" feature is controlled via browser.newtabpage.activity-stream.feeds.section.highlights. It would be great if you could follow the instructions at https://wiki.mozilla.org/CloudServices/Sync/File_a_desktop_bug, then reproduce the bug, then attach the your log files. the about:sync addon will also help show you the "preferences" collection, so reporting what those 2 preference are in that collection, vs what they are on the PC itself would also be helpful.

I installed Your addon on Firefox Nightly and upload in the attachment a ZIP file with all its logs.
In addition I uploaded the error sync file from Firefox Beta on Lubuntu (there were no other sync logs, maybe due to services.sync.log.appender.file.logOnSuccess being set to false).

Hope this helps.

Comment 5

[Mic Sparrow]

Attachment: aboutsync-logfiles.zip

ZIP packagae of syn logs form Nightly (Win 10).

Comment 6

[Mic Sparrow]

Attachment: error-sync-1606840777917.txt

Error sync log from Firefox Beta (Lubuntu).

Comment 7

[Mark Hammond [:markh] [:mhammond]]

There's certainly something odd going on here. The linux machine appears to have only recently (as in, only a few hours ago) signed in to the Firefox Account - is that expected? Firefox also seems confused about the state of the "prefs" engine - it can't decide if it should be enabled or not. If you visit about:config and look for the services.sync.declinedEngines preference, I think you will find "prefs" in it, even though I suspect the UI will show preferences are syncing - it would be interesting to know whether removing "prefs" from that pref (and the comma before/after it) helps in any way.

Comment 8

[Mic Sparrow]

(In reply to Mark Hammond [:markh] [:mhammond] from comment #7)

There's certainly something odd going on here. The linux machine appears to have only recently (as in, only a few hours ago) signed in to the Firefox Account - is that expected? Firefox also seems confused about the state of the "prefs" engine - it can't decide if it should be enabled or not. If you visit about:config and look for the services.sync.declinedEngines preference, I think you will find "prefs" in it, even though I suspect the UI will show preferences are syncing - it would be interesting to know whether removing "prefs" from that pref (and the comma before/after it) helps in any way.

It may be my caused by me as I decided to log out and in to Firefox sync hoping it fixes itself before taking the logs.
Regarding the second part of your message - probably yes, as disselecting the prefs from sync options fixes the problem.

Comment 9

[Mark Hammond [:markh] [:mhammond]]

(In reply to Mic Sparrow from comment #8)

Regarding the second part of your message - probably yes, as disselecting the prefs from sync options fixes the problem.

The odd thing I could see is that even when prefs was enabled, it was listed in services.sync.declinedEngines, which generally shouldn't be the case.

Regardless, I think that to make any further progress here, we probably need that addon installed on your Linux box (which has the side-effect of adjusting the log levels etc), then wait some time (at least until the problem happens again a couple of times), then get new logs from both machines.

Comment 10

[Mic Sparrow]

(In reply to Mark Hammond [:markh] [:mhammond] from comment #9)

(In reply to Mic Sparrow from comment #8)

Regarding the second part of your message - probably yes, as disselecting the prefs from sync options fixes the problem.

The odd thing I could see is that even when prefs was enabled, it was listed in services.sync.declinedEngines, which generally shouldn't be the case.

Regardless, I think that to make any further progress here, we probably need that addon installed on your Linux box (which has the side-effect of adjusting the log levels etc), then wait some time (at least until the problem happens again a couple of times), then get new logs from both machines.

So far it seems that deleting the "prefs" entry in "services.sync.declinedEngines" partially resolves the issue as now only DRM settings gets turned off in FF Beta Lubuntu and less often. The preferences/options are set to sync.

Comment 11

[Mic Sparrow]

(In reply to Mic Sparrow from comment #10)

(In reply to Mark Hammond [:markh] [:mhammond] from comment #9)

(In reply to Mic Sparrow from comment #8)

Regarding the second part of your message - probably yes, as disselecting the prefs from sync options fixes the problem.

The odd thing I could see is that even when prefs was enabled, it was listed in services.sync.declinedEngines, which generally shouldn't be the case.

Regardless, I think that to make any further progress here, we probably need that addon installed on your Linux box (which has the side-effect of adjusting the log levels etc), then wait some time (at least until the problem happens again a couple of times), then get new logs from both machines.

So far it seems that deleting the "prefs" entry in "services.sync.declinedEngines" partially resolves the issue as now only DRM settings gets turned off in FF Beta Lubuntu and less often. The preferences/options are set to sync.

Deleting this entry in both devices. So far DRM settings turned off only one time.

Comment 12

[Mark Hammond [:markh] [:mhammond]]

There are 2 distinct problems here:

• One is that somehow the services.sync.declinedEngines pref got confused - so we'd end up in a situation where we synced the preferences, then at the end decided that it should be disabled - so we nuked the guid and marked it as declined. Then the next sync seemed to do the same thing - but because the guid had changed, it was a "reset" and prefs were re-synced - hence every sync seems to update the prefs collection (whereas normally, it should update only when one of the synced prefs changes, which should be relatively rare. We should fix the possibility of this confusion as part of bug 1580071.

• The other is that then the preferences do sync (which happened too often due to the above, but will still happen occasionally), at least the 2 prefs media.eme.enabled preference and browser.newtabpage.activity-stream.feeds.section.highlights are behaving strangely - almost as though they have different default values between the 2 platforms - but that doesn't seem to be the case. Probably the only way I can diagnose that is to get logs from both machines, as described in comment 9.

Comment 13

[Mic Sparrow]

Attachment: aboutsync-logfiles-nighty.zip

Log files from Nightly (win 10).

Comment 14

[Mic Sparrow]

Attachment: aboutsync-logfiles-beta.zip

Log files from FF Beta (Linux).

Comment 15

[Mic Sparrow]

(In reply to Mark Hammond [:markh] [:mhammond] from comment #12)

There are 2 distinct problems here:

• One is that somehow the services.sync.declinedEngines pref got confused - so we'd end up in a situation where we synced the preferences, then at the end decided that it should be disabled - so we nuked the guid and marked it as declined. Then the next sync seemed to do the same thing - but because the guid had changed, it was a "reset" and prefs were re-synced - hence every sync seems to update the prefs collection (whereas normally, it should update only when one of the synced prefs changes, which should be relatively rare. We should fix the possibility of this confusion as part of bug 1580071.

• The other is that then the preferences do sync (which happened too often due to the above, but will still happen occasionally), at least the 2 prefs media.eme.enabled preference and browser.newtabpage.activity-stream.feeds.section.highlights are behaving strangely - almost as though they have different default values between the 2 platforms - but that doesn't seem to be the case. Probably the only way I can diagnose that is to get logs from both machines, as described in comment 9.

I sent the log files from Your addon after the whole day (yesterday) of using both Firefox.

Comment 16

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:rfkelly, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 17

[Mark Hammond [:markh] [:mhammond]]

So best I can tell, you probably have the Firefox that comes with Lubuntu, and that distribution has changed the default values of these 2 preferences. Basically, Sync is recording that the value has the default value - which is different in the official and lubuntu builds. Sadly, I don't think there's much we can do about that without redesigning how prefs are synced.

Comment 18

[Mic Sparrow]

(In reply to Mark Hammond [:markh] [:mhammond] from comment #17)

So best I can tell, you probably have the Firefox that comes with Lubuntu, and that distribution has changed the default values of these 2 preferences. Basically, Sync is recording that the value has the default value - which is different in the official and lubuntu builds. Sadly, I don't think there's much we can do about that without redesigning how prefs are synced.

But the Lubuntu Firefox is not the built-in. This is a beta release downloaded from the archive.firefox site.

Comment 20

[BugBot [:suhaib / :marco/ :calixte]]

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Comment 21

[Mark Hammond [:markh] [:mhammond]]

The patch I'm landing in bug 1731249 also handles every pref identified in this bug (eg, DRM, pocket, etc), so I'm closing this as a dupe of that. Note that all clients you use will need to update to the version with that patch before it will work correctly (ie, just waiting for a Firefox Nightly, but not waiting for your linux distro to release a new version with the patch will still have the problem)