UI Telemetry for Settings records empty preference name

RESOLVED FIXED in Firefox 33

Status

()

Firefox for Android
General
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: liuche, Assigned: Margaret)

Tracking

(Blocks: 1 bug)

Trunk
Firefox 35
ARM
Android
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox33 fixed, firefox34 fixed, firefox35 fixed)

Details

Attachments

(1 attachment, 1 obsolete attachment)

Under edit.1 > Setttings events, some of the preferences do not have a string extra of the preference name that is being changed or accessed. This may be due to navigating between Preferences screens or something else, but in any case, the empty pref name is not useful information.
(Assignee)

Updated

4 years ago
Blocks: 1063114
(Assignee)

Updated

4 years ago
Assignee: nobody → margaret.leibovic
(Assignee)

Comment 1

4 years ago
I found that this is happening for the link-like preferences we have that don't have keys. However, we do have keys for some of them, and those are showing up (e.g. android.not_a_preference.geo.learn_more), so I think we should just make sure we have keys for every preference, and that will help the probe catch all the data.
(Assignee)

Comment 2

4 years ago
Created attachment 8484636 [details] [diff] [review]
Make sure all preferences have keys

I went through all the preferences, and I believe this catches them all.

I went with the not_a_preference pattern we use elsewhere.
Attachment #8484636 - Flags: review?(liuche)
Comment on attachment 8484636 [details] [diff] [review]
Make sure all preferences have keys

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

Since we don't care about the preference "value" of these "prefs", you should also set android:persistent to be false - that way, Android won't create a SharedPreference key-value for each of these fake preferences.

::: mobile/android/base/resources/xml/preferences_devtools.xml
@@ +15,5 @@
>         <CheckBoxPreference android:key="devtools.debugger.remote-enabled"
>                             android:title="@string/pref_developer_remotedebugging" />
>  
> +       <org.mozilla.gecko.preferences.AlignRightLinkPreference android:key="android.not_a_preference.remote_debugging.link"
> +                                                               android:title="@string/pref_learn_more"

Also add android:persistent="false".
Attachment #8484636 - Flags: review?(liuche) → review+
(Assignee)

Comment 4

4 years ago
(In reply to Chenxia Liu [:liuche] from comment #3)
> Comment on attachment 8484636 [details] [diff] [review]
> Make sure all preferences have keys
> 
> Review of attachment 8484636 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Since we don't care about the preference "value" of these "prefs", you
> should also set android:persistent to be false - that way, Android won't
> create a SharedPreference key-value for each of these fake preferences.
> 
> ::: mobile/android/base/resources/xml/preferences_devtools.xml
> @@ +15,5 @@
> >         <CheckBoxPreference android:key="devtools.debugger.remote-enabled"
> >                             android:title="@string/pref_developer_remotedebugging" />
> >  
> > +       <org.mozilla.gecko.preferences.AlignRightLinkPreference android:key="android.not_a_preference.remote_debugging.link"
> > +                                                               android:title="@string/pref_learn_more"
> 
> Also add android:persistent="false".

I also added this to the existing links that didn't have it.

https://hg.mozilla.org/integration/fx-team/rev/40de5e023fda
https://hg.mozilla.org/mozilla-central/rev/40de5e023fda
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 35
(Assignee)

Comment 6

4 years ago
I'm seeing at least one of these new keys in mfinkle's telemetry dashboard, but I'm also still seeing empty edit.1 > settings events. AIUI, these are "daily" events, which means the data comes from the day before mfinkle runs his script to update it. Is this correct? Could it just be that people haven't updated their builds? It's weird that there are so many more of these empty actions than the other actions.
Flags: needinfo?(mark.finkle)
(In reply to :Margaret Leibovic from comment #6)
> I'm seeing at least one of these new keys in mfinkle's telemetry dashboard,
> but I'm also still seeing empty edit.1 > settings events. AIUI, these are
> "daily" events, which means the data comes from the day before mfinkle runs
> his script to update it. Is this correct?

Correct

> Could it just be that people
> haven't updated their builds? It's weird that there are so many more of
> these empty actions than the other actions.

People don't update Nightly/Aurora as often as we'd like. It should start to trickle off, but you can also filter the data using BuildID.
Flags: needinfo?(mark.finkle)
(In reply to Mark Finkle (:mfinkle) from comment #7)

> > Could it just be that people
> > haven't updated their builds? It's weird that there are so many more of
> > these empty actions than the other actions.
> 
> People don't update Nightly/Aurora as often as we'd like. It should start to
> trickle off, but you can also filter the data using BuildID.

<too many to list>

I guess you can't filter by BuildID right now.
We could filter by Version, but We'd need to wait for 35a2 (aurora) to be released to see a difference.
(Assignee)

Updated

4 years ago
Blocks: 996753
(Assignee)

Comment 10

4 years ago
Created attachment 8490977 [details] [diff] [review]
Make sure all preferences have keys (patch that landed)

Approval Request Comment
[Feature/regressing bug #]: bug 996753
[User impact if declined]: we receive some empty telemetry settings events
[Describe test coverage new/current, TBPL]: no tests, landed on Nightly 9/8
[Risks and why]: very low risk, just adds telemetry probe
[String/UUID change made/needed]: none
Attachment #8490977 - Flags: approval-mozilla-beta?
Attachment #8490977 - Flags: approval-mozilla-aurora?
(Assignee)

Updated

4 years ago
Attachment #8490977 - Attachment is patch: true
(Assignee)

Updated

4 years ago
Attachment #8484636 - Attachment is obsolete: true
status-firefox33: --- → affected
status-firefox34: --- → affected
status-firefox35: --- → fixed
Attachment #8490977 - Flags: approval-mozilla-beta?
Attachment #8490977 - Flags: approval-mozilla-beta+
Attachment #8490977 - Flags: approval-mozilla-aurora?
Attachment #8490977 - Flags: approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.