Closed Bug 2042309 Opened 2 months ago Closed 2 months ago

about:preferences#privacy is broken with MOZ_DATA_REPORTING false

Categories

(Firefox :: Settings UI, defect)

Desktop
All
defect

Tracking

()

RESOLVED FIXED
153 Branch
Tracking Status
firefox-esr140 --- unaffected
firefox151 --- wontfix
firefox152 - fixed
firefox153 --- fixed

People

(Reporter: pierov, Assigned: any1here)

References

Details

Attachments

(3 files, 1 obsolete file)

Some preferences aren't registered when MOZ_DATA_REPORTING is false (https://searchfox.org/firefox-main/rev/9d2be0cb8dbf1c3a7ef6ba79be35d637d0327eaa/browser/components/preferences/config/permissions-data.mjs#62-72).

However, that triggers this JS error:

Uncaught PreferenceNotAddedError: Setting "submitHealthReportBox" was unable to find Preference "datareporting.healthreport.uploadEnabled". Did you register it with Preferences.add/addAll?
    PreferenceNotAddedError chrome://global/content/preferences/Setting.mjs:185
    Setting chrome://global/content/preferences/Setting.mjs:254
    addSetting chrome://global/content/preferences/Preferences.mjs:101
    <anonymous> chrome://browser/content/preferences/config/permissions-data.mjs:350
    <anonymous> chrome://browser/content/preferences/privacy.js:13

An easy fix would be to register them regardless of MOZ_DATA_REPORTING and rely on their visible method not to show them.
That make almost all the other options visible again, but it leaves a confusing gap in the page, mostly due to the margin of the hidden options (see the attached screenshot).

STR:

Apply this diff:

diff --git a/browser/moz.configure b/browser/moz.configure
index 3ea3d88b9360..c55951b8debf 100644
--- a/browser/moz.configure
+++ b/browser/moz.configure
@@ -3,11 +3,11 @@
 # file, You can obtain one at http://mozilla.org/MPL/2.0/.
 
 imply_option("MOZ_PLACES", True)
-imply_option("MOZ_SERVICES_HEALTHREPORT", True)
+imply_option("MOZ_SERVICES_HEALTHREPORT", False)
 imply_option("MOZ_SERVICES_SYNC", True)
 imply_option("MOZ_DEDICATED_PROFILES", True)
 imply_option("MOZ_BLOCK_PROFILE_DOWNGRADE", True)
-imply_option("MOZ_NORMANDY", True)
+imply_option("MOZ_NORMANDY", False)
 imply_option("MOZ_PROFILE_MIGRATOR", True)
 
 

And set this in your mozconfig:

ac_add_options MOZ_TELEMETRY_REPORTING=
ac_add_options --disable-crashreporter

Alternatively, hardcode MOZ_DATA_REPORTING to False.

Flags: needinfo?(hjones)

Am I right in thinking this is a regression in 152 (as code appears to be from 1968118)? Also, you describe this as "partially broken" but I would actually be curious if any other settings still really work. JS exceptions in this type of location feel like they might break rather more - though it might depend on order of evaluation etc.

Flags: needinfo?(pierov)
OS: Unspecified → All
Hardware: Unspecified → Desktop
See Also: → 1968118

Actually, we found the problem in 151, not in 152. The code got moved a lot between in 151 and 152 (we still don't know about 153, we wait for Firefox to go to beta to rebase Tor Browser, but sometimes we are late and check even later).
I wrote partially because the panel appeared to be partially populated, but now that I have actually tried it, I confirm that privacy/security settings don't work. So, yes, it's totally broken, not partially.
However, other panels (general, home, etc) seem to work correctly.

Flags: needinfo?(pierov)
Summary: about:preferences#privacy is partially broken with MOZ_DATA_REPORTING false → about:preferences#privacy is broken with MOZ_DATA_REPORTING false

[Tracking Requested - why for this release]:
Privacy pane being broken in tor browser feels like something we need to address immediately. Unclear to me if an appropriate fix could be made for 151 at this point; it sounds like the code is materially different so requesting tracking for 152 only for now.

Assignee: nobody → any1here
Status: NEW → ASSIGNED

(In reply to :Gijs (he/him) from comment #3)

[Tracking Requested - why for this release]:
Privacy pane being broken in tor browser feels like something we need to address immediately. Unclear to me if an appropriate fix could be made for 151 at this point; it sounds like the code is materially different so requesting tracking for 152 only for now.

Thank you, we really appreciate this!
However please take into account that we use Firefox RR only for our development channel, while we keep the stable channel in the ESR.
So, since this is not a supported Firefox configuration, for us it will be enough if this is solved in 153, and we can do the needed backports 🙂️.
Thanks again!

Attachment #9590765 - Attachment is obsolete: true
Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → 153 Branch
Flags: needinfo?(hjones)

The patch landed in nightly and beta is affected.
:any1here, is this bug important enough to require an uplift?

For more information, please visit BugBot documentation.

Flags: needinfo?(any1here)

Created an uplift request just because the change seems very low risk/can only possibly fix things for a certain subset of users in 152

Flags: needinfo?(any1here)

firefox-beta Uplift Approval Request

  • User impact if declined/Reason for urgency: For certain users/under certain circumstances about:preferences is significantly broken due to preferences that were unnecessarily being added conditionally
  • Code covered by automated testing?: no
  • Fix verified in Nightly?: yes
  • Needs manual QE testing?: no
  • Steps to reproduce for manual QE testing:
  • Risk associated with taking this patch: low
  • Explanation of risk level: This change can only fix things for this subset of users - unconditionally registering preferences shouldn't impact any other users
  • String changes made/needed?: No
  • Is Android affected?: no
Attachment #9592156 - Flags: approval-mozilla-beta?
Attachment #9592156 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: