1831259 - The Forms and Autofill section and Always use private browsing mode Restart Firefox box were shown twice sometimes in the Privacy & Security Settings page

Status: VERIFIED FIXED

(Firefox :: Settings UI, defect, P3)

Description

[Matt Fagnani]

Attachment: Recording of the problem with Firefox 114.0a1 20230503214103

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

Steps to reproduce:

I started Firefox 114.0a1 20230503214103 on Wayland in Plasma 5.27.4 in a Fedora 38 KD Plasma installation. I selected the Edit > Settings in the menu bar. I selected the Privacy & Security page in Settings. The Forms and Autofill section had Autofill addresses and Autofill credit cards disabled. My profile normally had Always use private browsing mode selected. I clicked on Always use private browsing mode. I clicked on Restart Nightly Now in the Restart Firefox box showing Nightly must restart to disable this feature. I repeated the steps above many times to enable or disable Always use private browsing mode.

Actual results:

The Forms and Autofill section and Always use private browsing mode Restart Firefox box were shown twice sometimes in the Privacy & Security Settings page. The Forms and Autofill section was duplicated about 20% of the times I looked at the Privacy & Security Settings page. When the Forms and Autofill section was shown twice, the Always use private browsing mode Restart Firefox box was always shown again after clicking Restart Nightly Now. I'm attaching a recording of this problem. I've seen this problem occasionally in Firefox Nightly builds from the last few weeks at least.

Expected results:

The Forms and Autofill section and Always use private browsing mode Restart Firefox box should have been shown once in the Privacy & Security Settings page.

Comment 1

[:Gijs (out for now; he/him)]

I can't reproduce on a quick few attempts, but I can see how this could potentially happen. It's because pane initialization is async and I guess it's possible for it to be called twice, while the first initialization is still pending... That seems bad and I can at least fix that and then see if that resolves the issue for you.

Comment 2

[:Gijs (out for now; he/him)]

Attachment: Bug 1831259 - prevent initialization re-entrancy for preference panes, r=mconley

This should fix the issue experienced by the reporter. It also pushes the
re-entrancy guard into the the 'init' method we define on gCategoryInits
objects, and removes the asynchronicity which was only there for fluent's sake.

Instead of blocking the insertion on fluent, which meant that for the in-page
find functionality we do N initializations and fluent passes, we make each of
the 2 consumers responsible for checking translation has completed. This means
find in page now just has 1 fluent pass, instead of N passes for N categories.
This should speed up the find in page initialization, and means initialization
of a category is now sync instead of async.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/db1ae5bf8516
prevent initialization re-entrancy for preference panes, r=mconley

Comment 4

[Noemi Erli[:noemi_erli]]

Backed out changeset db1ae5bf8516 (Bug 1831259) for causing failures in browser_UsageTelemetry_interaction.js CLOSED TREE

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&collapsedPushes=842382&selectedTaskRun=J3sYFqV7Rt69iK2SxaItAQ.0&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&searchStr=linux%2C18.04%2Cx64%2Cwebrender%2Casan%2Copt%2Cmochitests%2Cwith%2Csoftware%2Cwebrender%2Cenabled%2Ctest-linux1804-64-asan-qr%2Fopt-mochitest-browser-chrome-swr%2Cbc8&revision=db1ae5bf85164cb02fff3d21af415aabf5aaf9fd

Log: https://treeherder.mozilla.org/logviewer?job_id=416737589&repo=autoland&lineNumber=3702

Backout: https://hg.mozilla.org/integration/autoland/rev/5e14d61584b960581f03b62a610f6d04d06be181

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/af6ffefb5572
prevent initialization re-entrancy for preference panes, r=mconley

Comment 6

[Cristian Tuns]

Backed out for causing bc failures in browser_aboutPrefs_fc_check_cantApply.js

• Backout link
• Push with failures
• Failure Log
• Failure line: TEST-UNEXPECTED-FAIL | toolkit/mozapps/update/tests/browser/browser_aboutPrefs_fc_check_cantApply.js | The panel's link should have non-empty textContent, got "" - "" == true - got "", expected true (operator ==)

Comment 7

[:Gijs (out for now; he/him)]

The change in bug 1835561 broke the patch by surfacing the racy issue that was already on file in bug 1835559, so this now has to wait for that bug to land.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c34f2e337a31
prevent initialization re-entrancy for preference panes, r=mconley

Comment 9

[Serban Stanca [:SerbanS]]

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

Comment 10

[:Gijs (out for now; he/him)]

I've asked for this to be backed out of Nightly given the 2 regressions that have just been filed and where we are in the cycle.

Comment 11

[Atila Butkovits]

Backed out as requested.

Backout link: https://hg.mozilla.org/mozilla-central/rev/bf811f65e32d6dadc0c73472c81a855f4c52451d

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f0bb54e03054
prevent initialization re-entrancy for preference panes, r=mconley

Comment 13

[Norisz Fay [:noriszfay]]

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

Comment 14

[Daniel Bodea [:danibodea]]

I cannot reproduce this issue either on my (Ubuntu) systems.
Matt Fagnani, does this issue still occur on your system in the latest Nightly and or latest Beta builds?
Help to verify this issue would be greatly appreciated.

Comment 15

[Matt Fagnani]

(In reply to Daniel Bodea [:danibodea] from comment #14)

I cannot reproduce this issue either on my (Ubuntu) systems.
Matt Fagnani, does this issue still occur on your system in the latest Nightly and or latest Beta builds?
Help to verify this issue would be greatly appreciated.

I haven't seen this problem in Nightly builds since the patch was merged in 116.0a1 20230607033033. I did see the problem once with 115.0 though. Thanks.

Comment 16

[Daniel Bodea [:danibodea]]

That is expected considering that the fix has only been pushed into branch 116 and went into branch 117 since then.
Thank you for the help!