Set default by UserChoice is sometimes attempted but rejected on Win 10 14393
Categories
(Firefox :: Shell Integration, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | unaffected |
firefox89 | --- | unaffected |
firefox90 | --- | unaffected |
firefox91 | --- | fixed |
People
(Reporter: agashlin, Assigned: agashlin)
References
(Blocks 2 open bugs, Regression)
Details
(Keywords: regression)
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
Looking at the distribution of errors for set default by UserChoice (login required), there are very few ErrExeRejected results, except for on Windows 10 build 14393 (Anniversary Update, 1609). This is the last major build before 15063 (Creators Update, 1703), which is when the current hash format was established. While there are 38 ErrHash results (which is what I'd expect, as an earlier hash format was used), there are also 12 ErrExeRejected, 24% of the results for this build, and 0 successes. Across all other versions (over 2000 results) there are only 7 rejections.
I don't know why the hash check passes sometimes on 14393, however it seems clear that we are not going to be able to set the hash correctly then, so we shouldn't try. I'll extend the current Win 10 check to check for a build of at least 15063.
Updated•3 years ago
|
Comment 1•3 years ago
|
||
Set release status flags based on info from the regressing bug 1703578
Updated•3 years ago
|
Assignee | ||
Comment 2•3 years ago
|
||
Assignee | ||
Comment 3•3 years ago
|
||
(In reply to Adam Gashlin (he/him) [:agashlin] from comment #0)
I'll extend the current Win 10 check to check for a build of at least 15063.
I ended up adding a separate check within setAsDefaultUserChoice()
, to avoid spreading the UserChoice logic further, and so that it can report a separate failure to telemetry. I still would like to figure out what causes this.
Comment 5•3 years ago
|
||
bugherder |
Updated•3 years ago
|
Description
•