Closed Bug 1731249 Opened 3 years ago Closed 2 years ago

Autoscroll setting unexpectedly disabled

Categories

(Firefox :: Sync, defect, P3)

Firefox 92
defect

Tracking

()

RESOLVED FIXED
104 Branch
Tracking Status
firefox104 --- fixed

People

(Reporter: jake, Assigned: markh)

References

Details

(Whiteboard: [fxsync-])

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:92.0) Gecko/20100101 Firefox/92.0

Steps to reproduce:

Unfortunately I don't know how to reproduce. On occasion, the setting will un-check from time to time. I think it occurs on startup, but I can't be certain. My best assumption is that something is funky with Sync, but that's a guess tbh.

Actual results:

I set Autoscroll to active by using Settings > General > Browsing > "Use autoscrolling". This was unset by default when I installed (installed on Pop!_OS 21.04, the Pop!_OS version of the Debian package). After a few uses (or many), the setting is unset and I have to go back in to enable it.

Expected results:

The "Use autoscrolling" setting should remain checked until I un-check it.

I have also noticed similar behavior with Settings > Home > Firefox Home Content > "Recommended by Pocket". I have to fix that more regularly.

Furthermore, I'd also like to note that I have Firefox synced between a desktop and laptop computer, both running Pop!_OS 21.04. I use each often and I find the problem to happen on both regularly.

Component: Untriaged → Sync

This sounds like bug 1678957 - the autoscroll preference has a default value which is different on Linux than Mac or Windows - however, it doesn't sound like you have a Mac or Windows device connected, so maybe it's something different?

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

This sounds like bug 1678957 - the autoscroll preference has a default value which is different on Linux than Mac or Windows - however, it doesn't sound like you have a Mac or Windows device connected, so maybe it's something different?

Sorry, I failed to mention that I am syncing to Windows 10 as well. My symptoms are different, but I would guess it's related to Sync as well -- I've had circumstances where the "Recommended by Pocket" section shows up on the Home screen a few moments after startup (like the option is getting updated by the Sync process).

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(markh)
Severity: -- → S3
Flags: needinfo?(markh)
Priority: -- → P3

Hi jake,
I was unable to reproduce the issue on Windows 10, on Firefox Nightly 95.0a1 (2021-10-25) (64-bit) and Release 93.0 (64-bit) versions.
Could you answer the following questions in order to further investigate this issue?

  1. Does this issue happen with a new profile? Here is a link on how to create a new profile: https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles

  2. Does this issue occur in the latest nightly version of firefox? Here is a link from where you can download it: https://www.mozilla.org/en-US/firefox/channel/desktop/

  3. Can you confirm if this issue is related with sync and the Pop!_OS 21.04? If you are still able to reproduce it, please, share further information with us, like a screen recording, or more specific steps.

I let the assigned a component in order to get the dev team involved.
'Firefox-Sync' team: if the component is not relevant please change it to a more appropriate one.

Regards,
Jerónimo.

Flags: needinfo?(jake)

(In reply to Jerónimo Torti from comment #5)

Hi jake,
I was unable to reproduce the issue on Windows 10, on Firefox Nightly 95.0a1 (2021-10-25) (64-bit) and Release 93.0 (64-bit) versions.
Could you answer the following questions in order to further investigate this issue?

I think there's enough details above to understand why you could not reproduce it.

Flags: needinfo?(jake)
QA Whiteboard: qa-not-actionable , qa-not-reproducible

This is certainly reproducible.

QA Whiteboard: qa-not-actionable , qa-not-reproducible → qa-not-actionable

I am having this same issue
Running Pop!_OS 20.04
For an unknown reason, auto-scroll will become disabled, and I will have to re-enable it

Having the same problem on Ubuntu 22.04 LTS which I dual boot with Windows 10.
Syncing settings through Firefox Account with Windows and Android and after enabling auto-scroll and rebooting, the autoscroll setting is unchecked yet again.

I've just found out, it happens when I'm using firefox on windows and then switching back to ubuntu autoscroll gets disabled!

Can we perhaps not sync auto-scroll across platform or so? Or we could change the autoscroll pref to be a tristate, but that probably requires changing the preferences UI which might be overkill.

Status: UNCONFIRMED → NEW
Ever confirmed: true

Yeah, that would be a simple fix and probably worthwhile - bug 1678957 implies there might be others, but there's no good reason not to fix just this pref in the meantime.

See Also: → 1678957

I've got a bit of a plan here. We already have the services.sync.prefs.sync. prefs branch. For prefs listed under that branch, we do not sync the value if it is the default value, but instead just sync that the pref has the default value. We do this primarily to handle prefs with a different value per channel - if you don't change the value on that channel, or change it back to the default for that channel, you probably don't want it to be applied to the other profile with a different default.

But that leads us to this current situation:

  • User on Linux adjusts general.autoScroll from the default false to true - no worries, we sync it.
  • Windows profile sees the new value come in - but true is the default there, so when it syncs prefs back out, it notes the pref is the default value.
  • Linux syncs again, sees the pref should be set to the default - so it goes back to false.

So another tweak we could make is: we can have a new branch, say, services.sync.prefs.sync-seen.. If a pref is noted in that branch, then we'd subtly change the behaviour, so that as soon as a non-default value is seen anywhere, we'd flag this as special - we'd then sync that pref always, even if the pref has the default value. So the behaviour would be the same until the user changes that pref on any platform - and once they did, it would forever sync regardless of the default.

We could consider doing that for all prefs (ie, once it's non-default once, anywhere, we sync it forever) but that seems much riskier to me, particularly for people "experimenting" with a pref they later set back to the default. IOW, the scheme above means you could "whitelist" specific prefs to get this behavior rather than making it the default.

I've got a reasonably modest patch for this. It adds general.autoScroll to this whitelist - that's the only pref I can identify which syncs by default with different values across platforms in official builds. However, as noted in comment 1 and in bug 1678957, there are apparently other prefs which 3rd-party distros modify (notably ones related to pocket and DRM), but we could whitelist these in later bugs once we can identify exactly which prefs are impacted. We might even be able to sync these new sync-seen prefs so that those other distros could even just add the new pref and other official builds would then start supporting the nominated pref in this way. OTOH though, distros which say "we don't want (say) DRM" may not be sympathetic to making it easy to enable DRM everywhere)

Any thoughts on that?

Whiteboard: [fxsync-]
Assignee: nobody → markh
Attachment #9282534 - Attachment description: WIP: Bug 1731249 - add an allow-list of prefs that will sync even if the default value. r?skhamis → Bug 1731249 - add an allow-list of prefs that will sync even if the default value. r?skhamis
Status: NEW → ASSIGNED
Pushed by mhammond@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/9ae65454bb7c add an allow-list of prefs that will sync even if the default value. r=skhamis
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 104 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: