Firefox does not open when clicking links in applications
Categories
(Firefox :: Launcher Process, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr91 | --- | unaffected |
firefox-esr102 | --- | unaffected |
firefox102 | --- | unaffected |
firefox103 | --- | unaffected |
firefox104 | --- | unaffected |
People
(Reporter: mbalfanz, Unassigned)
References
(Regression)
Details
(Keywords: regression)
With Firefox set as default browser, it doesn't open when clicking links in applications like CPU-Z or ParkControl.
STR
- Open Firefox (Nightly or Beta 103) and set it as default browser
- Open an app like ParkControl (https://bitsum.com/parkcontrol/) or CPU-Z (https://www.cpuid.com/softwares/cpu-z.html)
- Click any link in the application, like "Get Process Lasso" or "Activate Now > Purchase Activiation Code" in ParkControl
ER
- Firefox should open the URL
AR
- Nothing happens
I can reproduce this problem on Windows 10 and 11. It works with Firefox stable 102. I couldn't test similar behavior on MacOS.
:bogdan_maris helped to find the following regression range: https://hg.mozilla.org/mozilla-central/pushloghtml?changeset=213305a52f15418a036fd6ef8cc12231ad481690
Comment 1•3 years ago
|
||
I also tried to reproduce on other platforms (Ubuntu and Mac) but I was unable to. Based on that I think this is Windows only but I might be wrong, the apps from comment 0 are only available on Windows. Apps used for non-Windows platform:
- Ubuntu: Gnome Tweaks, Kazam, Gimp, Wireshark, CPU-X
- Mac: workspace, mozregression gui, Adobe Acrobat Reader, BBEdit
Comment 2•3 years ago
|
||
Do these applications run in an elevated context? (Eg: do you run them as administrator or get a UAC prompt before launching them?) If so, this might be the same as https://bugzilla.mozilla.org/show_bug.cgi?id=1778252.
Regardless, I have a feeling this may be related to the work done in https://bugzilla.mozilla.org/show_bug.cgi?id=1733821 given what's in the regression range. Ray - do you have any ideas about this?
Comment 3•3 years ago
|
||
The changes in bug 1733821 should have no effect unless Firefox was going to go into an infinite loop. Even if they did, I'd expect adding -no-deelevate
to the appropriate registry entry [*] would prevent it; but that has no effect. I'm certainly not going to say it's not possible, but I don't immediately see how.
I concur that this looks like the same behavior as bug 1778252, and will comment further there.
[*] HKLM\SOFTWARE\Classes\FirefoxURL-<hexstring>\shell\open\command
, where FirefoxURL-<hexstring>
is obtained from HKCU\SOFTWARE\Microsoft\Windows\Shell\Associations\UrlAssociations\https\UserChoice
. (I hope.)
Reporter | ||
Comment 4•3 years ago
|
||
I can confirm that both applications show a UAC prompt before launching them.
Comment 5•3 years ago
•
|
||
... although actually, the simplest way to check if it's bug 1733821 is probably to try to repro this in a local build with D149545 and D149546 reverted.
If that fixes this behavior, I think it's worth committing the revert and uplifting to beta — although the other issue presents as more severe, it requires the user to be in a very unusual configuration, and a workaround is known. Neither of those are true here.
Comment 6•3 years ago
|
||
(In reply to Ray Kraesig [:rkraesig] from comment #5)
... although actually, the simplest way to check if it's bug 1733821 is probably to try to repro this in a local build with D149545 and D149546 reverted.
If that fixes this behavior, I think it's worth committing the revert and uplifting to beta — although the other issue presents as more severe, it requires the user to be in a very unusual configuration, and a workaround is known. Neither of those are true here.
I gave this a shot in https://treeherder.mozilla.org/jobs?repo=try&revision=10f922833bd89a1df189a05b1aa94f0d397fd97a and reverting those two patches appears to fix this issue.
Updated•3 years ago
|
Comment 7•3 years ago
|
||
(In reply to bhearsum@mozilla.com (:bhearsum) from comment #6)
I gave this a shot in https://treeherder.mozilla.org/jobs?repo=try&revision=10f922833bd89a1df189a05b1aa94f0d397fd97a and reverting those two patches appears to fix this issue.
Sadness. Can you go ahead and send that revert patch into Phabricator? I'll rubber-stamp it and we can get the uplift process started afterwards.
Updated•3 years ago
|
Comment 9•3 years ago
•
|
||
I can't repro this when I tested using CPU-Z 2.01.0, CCleaner Portable 5.91 and Autoruns 14.09 on FF 103.0b5 x64. Opens right up in a new tab when I click a link in any app. FF is my default browser. Using Win 10 22H2 19045.1806 on a crummy Latitude E6500 and restricted user AD account.
I also saw duplicate bug 1778252 above. I have UAC disabled if it at all matters.
Comment 10•3 years ago
|
||
Any chance that you could:
- With FF running, ctrl-shift-j to bring up error console
- Click the garbage can at top-left to clear the screen
- Launch CPU-Z and click the link in the About tab
- Go back to Error Console and see if any error shows up there
Comment 11•3 years ago
|
||
Marking 103 and 104 as unaffected - the regressor bug 1733821 was reverted in central and beta
Comment 13•3 years ago
|
||
(In reply to Donal Meehan [:dmeehan] from comment #11)
Marking 103 and 104 as unaffected - the regressor bug 1733821 was reverted in central and beta
In which 103 beta was the change reverted (bug 1733821) that it would be noticeable?
Comment 14•3 years ago
|
||
With the bug 1733821 fix applied, EnsureCommandlineSafe will block launching because of the extra --attempting-deelevation
option.
Comment 15•3 years ago
|
||
(In reply to Arthur K. [He/Him] from comment #13)
(In reply to Donal Meehan [:dmeehan] from comment #11)
Marking 103 and 104 as unaffected - the regressor bug 1733821 was reverted in central and beta
In which 103 beta was the change reverted (bug 1733821) that it would be noticeable?
The revert will be part of the next beta build - 103.0b6.
103.0b6 build starts at 21:00 UTC 2022-07-07, and the update will be available a couple of hours later.
Comment 16•3 years ago
|
||
(In reply to Donal Meehan [:dmeehan] from comment #15)
(In reply to Arthur K. [He/Him] from comment #13)
(In reply to Donal Meehan [:dmeehan] from comment #11)
Marking 103 and 104 as unaffected - the regressor bug 1733821 was reverted in central and beta
In which 103 beta was the change reverted (bug 1733821) that it would be noticeable?
The revert will be part of the next beta build - 103.0b6.
103.0b6 build starts at 21:00 UTC 2022-07-07, and the update will be available a couple of hours later.
Still odd that it doesn't repro for me.
Comment 17•3 years ago
|
||
I can't seem to reproduce this anymore with the latest builds of Nightly (2022-07-11) and Beta (beta7) in Windows 10 and Windows 11 using the two programs initially reported CPU-Z and ParkControl. I will go ahead and call this Verified Fixed by backing out bug 1733821.
Updated•3 years ago
|
Description
•