Closed Bug 1625457 Opened 4 years ago Closed 4 years ago

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

Categories

(Firefox :: Settings UI, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 76
Tracking Status
firefox-esr68 --- unaffected
firefox74 --- wontfix
firefox75 --- fixed
firefox76 --- fixed

People

(Reporter: acat, Assigned: Gijs)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

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.

Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED

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

Summary: Privacy section in Preferences does not work in MOZ_TELEMETRY_REPORTING=false builds → Privacy section in Preferences does not work in MOZ_DATA_REPORTING=false builds
Pushed by jwein@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/de1b297a3ec0
fix privacy pane when MOZ_DATA_REPORTING=false, r=jaws
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 76

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
Attachment #9136320 - Flags: approval-mozilla-beta?

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

approved for 75rc1, thanks

Attachment #9136320 - Flags: approval-mozilla-beta? → approval-mozilla-release+
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: