1744021 - [win] Text inside about:preferences updates section flashes when changing from automatically to manual updates

Status: RESOLVED FIXED

(Firefox :: Settings UI, defect, P3)

Description

[Alexandru Trif, Desktop QA [:atrif]]

Attachment: updates_preferences.gif

Affected versions

• 96.0a1 (20211201214955)
• 95.0 (20211129150630)
• 94.0.2 (20211119140621)
• 91.3.0esr (20211028170545)

Affected platforms

• Windows10 x64

Steps to reproduce

1. Open Firefox and about:preferences.
2. Scroll down to the updates section and change between automatically to manual and vice versa.
3. Observe the text from the downloads section.

Expected result

• The text is displayed as expected when switching is performed.

Actual result

• Text flashes on this section when switching from automated to manual.

Regression range

• Last good revision: 6e842238034cd847ede178b4e65ea07704e4ffe6 (2018-11-06)
  First bad revision: 5836a60614764631436bf5030c5baa34c676c7a2 (2018-11-07)
  Pushlog:
  https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6e842238034cd847ede178b4e65ea07704e4ffe6&tochange=5836a60614764631436bf5030c5baa34c676c7a2

Notes

• Screen recording attached.
• Checking/ Unchecking When Nightly is not running also causes flashes on this text only, and not to the whole updates section.

Comment 1

[Robin Steuber (they/them) [:bytesized]]

This is pretty much the expected behavior. I'm open to changing it, but I'm not sure what to change it to.

This setting is not controlled by a standard pref, it's written to update_config.json. While the write is in-progress, the control is disabled. Once the write has completed, the control is re-enabled and its value is updated. This is what causes the "flash": the section being disabled and re-enabled.

Unfortunately, I'm not entirely sure how to do better. Here are some potential solutions that I think are unattractive:

• We could leave the control enabled the whole time. As things currently are, this would mean that when the control is clicked, nothing would immediately happen. Then, once the write had completed, the radio selection would jump to the selected value. Potentially, multiple writes could even be queued up, causing the radio selection to jump around erratically.
• We could leave the control enabled and move the selection immediately, then move it back on failure. This seems unattractive because we could end up with an experience where we indicated that we changed the setting, but then changed it back when the user wasn't looking. Even if we display an error message, it may be confusing to the user if they have moved on from that setting.
• We could add some sort of "in-progress" user interface (ex: a gear turning while the setting saves to disk). This seems like the most attractive option, but it would be inconsistent with the rest of the page for no obvious reason and would probably require UI design from a team that (last I heard) is extremely busy.

Comment 2

[:Gijs (he/him)]

Attachment: Bug 1744021 - force the update prefs to be disabled for at least one second when changing them, r?bytesized

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1a5efeaef0a9
force the update prefs to be disabled for at least one second when changing them, r=bytesized,preferences-reviewers,mstriemer

Comment 4

[Narcis Beleuzu [:NarcisB]]

Backed out for bc failures on browser_aboutPrefs_settings.js

Backout link: https://hg.mozilla.org/integration/autoland/rev/00d3e0f20e2c8798f4ca39d2d84952222b1fdd5b
Log link: https://treeherder.mozilla.org/logviewer?job_id=360852884&repo=autoland&lineNumber=9970

Comment 5

[:Gijs (he/him)]

(In reply to Narcis Beleuzu [:NarcisB] from comment #4)

Backed out for bc failures on browser_aboutPrefs_settings.js

Backout link: https://hg.mozilla.org/integration/autoland/rev/00d3e0f20e2c8798f4ca39d2d84952222b1fdd5b
Log link: https://treeherder.mozilla.org/logviewer?job_id=360852884&repo=autoland&lineNumber=9970

Ugh, this test is super racy. It clicks the item and expects that all processing (including both re-enabling the items so that the next change to the prefs "works", as well as clearing up any pending update files) is immediate, and now that the implementation enforces some waiting, it's exposing that raciness in the test, because the test moves on with the next step even though we haven't finished processing the previous one.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ae00c00c2c50
force the update prefs to be disabled for at least one second when changing them, r=bytesized,preferences-reviewers,mstriemer,application-update-reviewers

Comment 7

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/ae00c00c2c50

Comment 8

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

The patch landed in nightly and beta is affected.
:Gijs, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.