Remove ProgID comparison from default browser check
Categories
(Firefox :: Shell Integration, task)
Tracking
()
Tracking | Status | |
---|---|---|
firefox91 | --- | fixed |
People
(Reporter: molly, Assigned: molly)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
Currently, in order to determine whether we are currently the default browser on Windows, we first check whether the current default's ProgID is a prefix match with a known Firefox one. After that, we also check that the path to the associated executable matches our installation path, and only report that we are the default browser if both match. But those checks are redundant; if the path check matches, there is no need to look at the ProgID, because we know that either our installer created that association and so the ProgID has to match, or otherwise the user created the association manually and the ProgID will not match, giving us a false negative. The redundant ProgID comparison should be removed.
Assignee | ||
Comment 1•4 years ago
|
||
Also switch to removing the quotes and command-line parameters from the command
string obtained from the registry before comparing it to our path, instead of
adding those things to our path, to make the comparison more reliable.
Assignee | ||
Updated•4 years ago
|
Updated•3 years ago
|
Assignee | ||
Comment 3•3 years ago
|
||
Now that all this is no longer a big secret, I should probably explain what this patch has to do with bug 1708830. Comment 0 is entirely correct, but what actually brought this bug about isn't mentioned there: it was the fact that the MSIX/AppX package installer generates its own ProgIDs for your app (one for each type you register), and they use their own format to name them, so they won't ever match the ones that we were computing to use here, and therefore a packaged installation would never think it was the default browser even if it was. It turns out to be kind of painful to retrieve those generated ProgIDs, and as comment 0 explains it isn't really necessary to check them here anyway, so the issue was worked around by simply removing the check. So now the default browser check works properly in packaged installations, and is also more reliable elsewhere.
Comment 4•3 years ago
|
||
bugherder |
Description
•