Closed Bug 1548646 Opened 7 months ago Closed 6 months ago

Preference name for "security.identitypopup.recordEventElemetry" misspelled

Categories

(Firefox :: Protections UI, defect, P5)

defect

Tracking

()

RESOLVED FIXED
Firefox 69
Tracking Status
firefox66 --- fixed
firefox67 --- wontfix
firefox68 --- wontfix
firefox69 --- fixed

People

(Reporter: jaws, Assigned: prem.kumar.krishnan, Mentored)

References

(Regression)

Details

(Keywords: good-first-bug)

Attachments

(1 file, 1 obsolete file)

The preference name is "security.identitypopup.recordEventElemetry" but it should be "security.identitypopup.recordEventTelemetry" (missing "T").

Both places where the preference is referenced will need to be updated. This will not affect Telemetry collection, but it would reset the pref for users who have toggled it independently. Therefore, we should continue reading the old spelling of the preference when checking the pref.

Hello, I am willing to work on this issue

Could you provide more details please? Like What component I have to work on?

Thanks for your interest. You can work on this. See the link in comment 1 for what files need changing.

The priority flag is not set for this bug.
:johannh, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jhofmann)
Flags: needinfo?(jhofmann)
Priority: -- → P5
Attached patch Patch for bug 1548646 (obsolete) — Splinter Review

Files firefox.js and BrowserGlue.jsm amended. Patch attached.

:jaws please review the patch.

Flags: needinfo?(jaws)
Comment on attachment 9069580 [details] [diff] [review]
Patch for bug 1548646

Review of attachment 9069580 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/components/BrowserGlue.jsm
@@ +1450,5 @@
>      }
>    },
>  
>    _recordContentBlockingTelemetry() {
> +    let recordIdentityPopupEvents = Services.prefs.getBoolPref("security.identitypopup.recordEventTelemetry");

As I mentioned in comment 0, "Therefore, we should continue reading the old spelling of the preference when checking the pref."
Attachment #9069580 - Flags: review-
Assignee: nobody → prem.kumar.krishnan
Status: NEW → ASSIGNED
Flags: needinfo?(jaws)

This is what I've understood so far about the bug. Correct me if I'm wrong.

Two references are made to this preference in the codebase (BrowserGlue.jsm and firefox.js)

firefox.js is basically the master of list of all default preferences.
Any preference change made by the user in (about:config) is stored under user preferences (prefs.js)

BrowserGlue.jsm pulls preferences from firefox.js and overrides it with values set in pref.js.

Won't it cause conflict if we update the spelling in one file (firefox.js) but not the other (browserglue.jsm)?

Flags: needinfo?(jaws)

If a user selectively changes a pref in firefox.js, and we remove that preference and replace it with a new name, the user-changed preference will remain. In that event, we can still check the old preference name to see if they have opted in to a specific behavior before checking the new preference name's value.

So the code in BrowserGlue.jsm can do as follows:

let recordIdentityPopupEvents = Services.prefs.prefHasUserValue("security.identitypopup.recordEventElemetry") ?  
                                Services.prefs.getBoolPref("security.identitypopup.recordEventElemetry") :
                                Services.prefs.getBoolPref("security.identitypopup.recordEventTelemetry");
Flags: needinfo?(jaws)

Got it. Revised patch attached.

Attachment #9069580 - Attachment is obsolete: true
Flags: needinfo?(jaws)
Comment on attachment 9069731 [details] [diff] [review]
Revised patch for Bug 1548646

Review of attachment 9069731 [details] [diff] [review]:
-----------------------------------------------------------------

thanks!
Attachment #9069731 - Flags: review+

Pushed by nbeleuzu@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/4f4de4742c98
correct misspelled preference name security.identitypopup.recordEventElemetry r=jaws

Keywords: checkin-needed
Status: ASSIGNED → RESOLVED
Closed: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 69
You need to log in before you can comment on or make changes to this bug.