Set pref browser.urlbar.eventTelemetry.enabled by default
Categories
(Firefox :: Address Bar, task, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr68 | --- | unaffected |
| firefox68 | --- | unaffected |
| firefox69 | blocking | verified |
| firefox70 | + | verified |
People
(Reporter: adw, Assigned: adw)
References
Details
(Keywords: rca-needed)
Attachments
(2 files)
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
999 bytes,
patch
|
RyanVM
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
[Tracking Requested - why for this release]:
[Tracking Requested - why for this release]:
There's a bug (not yet filed) with how Firefox handles webextensions that set prefs that do not exist by default. My top-sites extension sets browser.urlbar.eventTelemetry.enabled to true. That pref doesn't exist by default. If I install the extension, restart Firefox, and then uninstall or disable the extension, the pref remains set to true. It should be cleared instead. In contrast, if I install the extension but do not restart before uninstalling or disabling, the pref is cleared.
This is a showstopper for the top-sites experiment that we want to run on 69.
Fortunately a safe and simple workaround is to simply set browser.urlbar.eventTelemetry.enabled by default, i.e., add browser.urlbar.eventTelemetry.enabled to browser/app/profile/firefox.js.
I talked with Ryan and he says it's not too late for RC.
|
||
Updated•5 years ago
|
|
Assignee | |
Comment 1•5 years ago
|
||
Pushed by dwillcoxon@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/2f58aa289a3c Set pref browser.urlbar.eventTelemetry.enabled by default. r=harry
|
|
Assignee | |
Comment 3•5 years ago
|
||
Beta/Release Uplift Approval Request
- User impact if declined: Please see comment 0.
- 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: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): This patch simply adds a default pref. The pref controls some extra quantumbar telemetry. The pref did not exist by default, and this patch sets it to false by default, which is functionally the same thing. Re: test coverage, we have a test that covers this pref; however, it only tests with the pref flipped on. So to be clear, we don't have automated test coverage for the pref's default state of false/non-existent. This is a trivial patch though, so I don't consider that to be a concern.
- String changes made/needed: None
|
||
Comment 4•5 years ago
|
||
| bugherder | ||
|
|
Assignee | |
Comment 5•5 years ago
|
||
Marking this in-testsuite+, but see the caveat in comment 3.
|
|
Assignee | |
Comment 6•5 years ago
|
||
STR:
- Open about:config
- Search for
browser.urlbar.eventTelemetry.enabled. It should befalse. - Open about:telemetry in a new tab and select the Events section. There shouldn't be any events with the category "urlbar".
- Open a new tab, type "test", and hit enter to do a Google search (or whatever your default engine is).
- Go back to the about:telemetry tab and refresh. Again, there shouldn't be any "urlbar" events.
- Go back to the about:config tab and set
browser.urlbar.eventTelemetry.enabledtotrue. - Repeat step 4.
- Go back to the about:telemetry tab and refresh. This time, there should be a "urlbar" event, method is "engagement", object is "enter", value is "typed".
- Go back to the about:config tab and set
browser.urlbar.eventTelemetry.enabledtofalse. - Repeat step 4.
- Go back to the about:telemetry tab and refresh. The urlbar event from step 8 should still be there, but no new urlbar events should be present.
|
||
Updated•5 years ago
|
|
|
||
Comment 7•5 years ago
|
||
Comment on attachment 9087839 [details] [diff] [review] Beta/69 patch Set the pref by default to avoid incorrect behavior when running the experiment. Approved for 69.0rc1.
|
||
Comment 8•5 years ago
|
||
| bugherder uplift | ||
|
||
Comment 9•5 years ago
|
||
This is verified fixed on Firefox 70.a1 (latest) and 69.0b17 (from treeherder) using Windows 10x64, Windows 7x64, Ubuntu 18.04x64 and macOS 10.13.
|
||
Comment 10•4 years ago
|
||
This bug has been identified as part of a pilot on determining root causes of blocking and dot release drivers.
It needs a root-cause set for it. Please see the list at https://docs.google.com/document/d/1FFEGsmoU8T0N8R9kk-MXWptOPtXXXRRIe4vQo3_HgMw/.
Add the root cause as a whiteboard tag in the form [rca - <cause> ] and remove the rca-needed keyword.
If you have questions, please contact :tmaity.
Description
•