1625457 - Privacy section in Preferences does not work in MOZ_DATA_REPORTING=false builds

Status: RESOLVED FIXED

(Firefox :: Settings UI, defect)

Description

[Alex Catarineu (Tor Browser dev)]

In a build with MOZ_DATA_REPORTING=False, when trying to navigate to the Privacy & Security section in Preferences there's a TypeError: can't access property "addEventListener", document.getElementById(...) is null error, caused by https://searchfox.org/mozilla-central/rev/b712398b7fae54ef377a558d6f16dede7a7f8530/browser/components/preferences/in-content/privacy.js#506 trying to set a listener to the element with telemetryDataDeletionLearnMore with id, which does not exist when building with MOZ_TELEMETRY_REPORTING=False. Checking for AppConstants.MOZ_DATA_REPORTING before adding that listener fixes this for me.

Comment 1

[:Gijs (he/him)]

Attachment: Bug 1625457 - fix privacy pane when MOZ_DATA_REPORTING=false, r?jaws

Comment 2

[:Gijs (he/him)]

Both DATA and TELEMETRY reporting exist, but the ifdef in the markup uses DATA.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/de1b297a3ec0
fix privacy pane when MOZ_DATA_REPORTING=false, r=jaws

Comment 4

[Razvan Maries]

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

Comment 5

[:Gijs (he/him)]

Comment on attachment 9136320 [details]
Bug 1625457 - fix privacy pane when MOZ_DATA_REPORTING=false, r?jaws

Beta/Release Uplift Approval Request

• User impact if declined: builds without MOZ_DATA_REPORTING defined have a non-functional preference pane
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: n/a
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Very low-risk, we're just avoiding an error where a null element breaks initialization of the preference pane, by moving a single event listener addition to live behind a check that will only pass if the element on which we're adding a listener exists.

To be clear re: earlier answer: this code is covered by automated tests, and we know what regressed it, so we're confident the patch -- but the no-MOZ_DATA_REPORTING situation is not (and cannot really realiably be) covered by our tests. However, we can't really do worse there than a completely broken prefpane...

• String changes made/needed: n/a

Comment 6

[Julien Cristau [:jcristau]]

Comment on attachment 9136320 [details]
Bug 1625457 - fix privacy pane when MOZ_DATA_REPORTING=false, r?jaws

approved for 75rc1, thanks

Comment 7

[Julien Cristau [:jcristau]]

https://hg.mozilla.org/releases/mozilla-release/rev/897ce05e3c9e