`BROWSER_SET_DEFAULT_USER_CHOICE_RESULT` telemetry broken after Bug 1805509
Categories
(Firefox :: Messaging System, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr102 | --- | unaffected |
| firefox113 | --- | verified |
| firefox114 | --- | verified |
| firefox115 | --- | verified |
People
(Reporter: nalexander, Assigned: beth)
References
(Regression)
Details
(Keywords: regression)
Attachments
(2 files)
|
48 bytes,
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-beta+
RyanVM
:
approval-mozilla-release+
|
Details | Review |
|
343.40 KB,
image/png
|
Details |
There's a clear change from Success to ErrOther between Firefox 111 and Firefox 112 that I attribute, without being 100% certain, to Bug 1805509.
I think the issue is that the new _handleWDBAResult call isn't necessarily updating this.telemetryResult, but I've not dug into this.
| Reporter | ||
Comment 1•2 years ago
|
||
brennie: do you have bandwidth to address this?
Comment 2•2 years ago
|
||
Set release status flags based on info from the regressing bug 1805509
| Assignee | ||
Comment 3•2 years ago
|
||
The old code would set telemetryResult = Success after a successful operation, but that line got dropped in the refactor. Should be an easy fix.
| Assignee | ||
Comment 4•2 years ago
|
||
Updated•2 years ago
|
Comment 6•2 years ago
|
||
| bugherder | ||
Comment 7•2 years ago
|
||
The patch landed in nightly and beta is affected.
:barret, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- If no, please set
status-firefox114towontfix.
For more information, please visit BugBot documentation.
| Assignee | ||
Comment 8•2 years ago
|
||
Comment on attachment 9332457 [details]
Bug 1832132 - Correctly report success in BROWSER_SET_DEFAULT_USER_CHOICE_RESULT r?nalexander
Beta/Release Uplift Approval Request
- User impact if declined: None. This only affects telemetry.
- 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 only affects the string returned in the success case for BROWSER_SET_DEFAULT_USER_CHOICE_RESULT telemetry.
- String changes made/needed:
- Is Android affected?: No
Comment 9•2 years ago
•
|
||
Comment on attachment 9332457 [details]
Bug 1832132 - Correctly report success in BROWSER_SET_DEFAULT_USER_CHOICE_RESULT r?nalexander
Approved for 114.0b3 and 113.0.1.
Comment 10•2 years ago
|
||
| bugherder uplift | ||
Comment 11•2 years ago
|
||
| bugherder uplift | ||
| Reporter | ||
Comment 12•2 years ago
|
||
Returning to this: in https://glam.telemetry.mozilla.org/firefox/probe/browser_set_default_user_choice_result/explore?activeBuckets=%5B%22Success%22%2C%22ErrProgID%22%2C%22ErrHash%22%2C%22ErrLaunchExe%22%2C%22ErrExeTimeout%22%2C%22ErrExeProgID%22%2C%22ErrExeHash%22%2C%22ErrExeRejected%22%2C%22ErrExeOther%22%2C%22ErrOther%22%5D&aggregationLevel=version&channel=release¤tPage=1&os=Windows&process=parent, I see a clear return to the expected success rate. See attached screen shot.
| Reporter | ||
Comment 13•2 years ago
|
||
Comment 14•2 years ago
|
||
Considering the fact that the success rate is visible, I'm closing this bug as verified. Thanks!
Comment 15•2 years ago
|
||
We have this bug suggesting the issue may not be fixed. Would it be possible to re-verify this on the latest releases?
Comment 16•2 years ago
|
||
Hi Shane! I'll take a look today and I'll leave a comment with the outcome.
Thanks!
Comment 17•2 years ago
|
||
Hi Shane! We have left a comment on the mentioned issue.
Thank you!
Description
•