Launching URIs fails when explorer.exe is not running
Categories
(Firefox :: File Handling, defect, P3)
Tracking
()
People
(Reporter: kenneth, Assigned: toshi)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.100 Safari/537.36
Steps to reproduce:
Kill Windows explorer and URI launch will stop working.
example URI:
steam://connect/ipaddress
esportal://arg/arg
Actual results:
Nothing happens, the following error is observed in the console:
NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIHandlerInfo.launchWithURI] 6 dialog.js:349
onOK chrome://mozapps/content/handling/dialog.js:349
initialize chrome://mozapps/content/handling/dialog.js:147
_fireButtonEvent chrome://global/content/elements/dialog.js:537
_doButtonCommand chrome://global/content/elements/dialog.js:516
_handleButtonCommand chrome://global/content/elements/dialog.js:510
_handleButtonCommand self-hosted:876
(Async: EventListener.handleEvent)
_configureButtons chrome://global/content/elements/dialog.js:382
connectedCallback chrome://global/content/elements/dialog.js:184
<anonym> chrome://global/content/customElements.js:219
(Async: EventListener.handleEvent)
<anonym> chrome://global/content/customElements.js:211
<anonym> chrome://global/content/customElements.js:820
observe resource://gre/modules/CustomElementsListener.jsm:24
Expected results:
The appropriate applications should launch.
Comment 1•5 years ago
|
||
:toshi, can you take a look at what our options are here? I'm not sure how many we really have, or if we can distinguish this from other ways in which we could fail to validate the URI...
Assignee | ||
Comment 2•5 years ago
|
||
I think we need to add a fallback in nsMIMEInfoWin::LoadUriInternal
as we did for bug 1602726. I'll try it tomorrow.
Assignee | ||
Comment 3•5 years ago
|
||
After I kill explorer.exe, ShellExecuteEx
cannot launch any uri (I tried http, microosft-edge, and ms-settings.), but I assume your custom shell can handle steam: or esportal:. With your shell (without explorer.exe), when you run a command start steam://connect/ipaddress
on cmd.exe, do you see the expected behavior? If so, a fallback logic will help this case because cmd.exe actually does ShellExecuteEx
.
I'll share a private build of Nightly with a fallback so that you can verify the change.
Assignee | ||
Comment 4•5 years ago
|
||
Here are the binaries with a fallback in nsMIMEInfoWin::LoadUriInternal
.
32bit: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/FIK08KtlQACU2cbu6GEnYg/runs/0/artifacts/public/build/target.zip
64bit: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/fZxFM5LQShy3vWKD_yPpQA/runs/0/artifacts/public/build/target.zip
Hi,
Indeed i see the same behavior as you when killing explorer it does not work, but with our shell running it looks like it is working perfect.
I am forwarding this build to further testing both internally and to our client who reported the issue, will report back as soon as they verify that this issue have been resolved for us. How long does it usually take for a fix like this to end up on your release branch, once it is confirmed?
Thank you so much this far guys, what a great support experience :)
i can confirm that this issue have been resolved for us, thanks.
How long does it usually take before this arrives in the official nightly build?
Assignee | ||
Comment 7•5 years ago
|
||
If a system uses a custom shell instead of Windows Explorer,
ShellExecuteByExplorer
always fails though the custom shell can handle it.
We added a fallback for a local file to address Bug 1602726. This patch adds
a fallback for a uri.
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Comment 8•5 years ago
|
||
(In reply to Koenig from comment #6)
i can confirm that this issue have been resolved for us, thanks.
How long does it usually take before this arrives in the official nightly build?
Thank you for validating the patch. I started code review just now. Once it's approved, it's usually released in the next day's build.
Comment 9•5 years ago
|
||
Kill Windows explorer and URI launch will stop working.
Just out of interest. How do you work when Windows Explorer isn't running?
Reporter | ||
Comment 10•5 years ago
|
||
(In reply to Jorg K (GMT+1) from comment #9)
Kill Windows explorer and URI launch will stop working.
Just out of interest. How do you work when Windows Explorer isn't running?
The system we offer is a launching system widely used on esport centers/internet cafes. the users of the machines are restricted to only launch predefined applications/games set up internally in our system. By restricting general access to the pc, the machines remains protected from misuse.
Assignee | ||
Comment 11•5 years ago
|
||
Actually I'm also curious how a custom shell can handle a custom uri for ShellExecute
without explorer.exe because in my understanding ShellExecute
is for explorer.exe. One idea I can think of is to hook ShellExecute
in firefox.exe. Could you share some technical details if possible? It would help us test some scenarios on our end.
Updated•5 years ago
|
Reporter | ||
Comment 12•5 years ago
|
||
To be honest, i was a bit surprised that this worked myself. To my knowledge we have not done anything special to handle this scenario. We are not hooking into windows to handle this, and certainly not firefox.
I suspect that behind the scenes ShellExecute ends up in a normal Process.Start() and the reason it fails without explorer.exe running is that some information is attempted to be sent to the current shell - if this fails, the Process.Start() is never reached. I suspect that it does not matter what application is been used as shell - as long as it is running, then shellexecute will work.
Process.Start() can handle URI without problems, it will translate that into an application all by itself without the shell, and i think chrome uses this method to start external applications, given that this has never been an issue in chrome.
Comment 13•5 years ago
|
||
ShellExecute
is implemented by in-process shell32.dll. Bug 1567614 (inheriting mitigation policies from the host process) happened for that very reason.
Updated•5 years ago
|
Comment 14•5 years ago
|
||
Comment 15•5 years ago
|
||
bugherder |
Comment 16•5 years ago
|
||
This sounds edge-case enough to not worry about uplifting to ESR. Feel free to nominate if you feel strongly otherwise.
Description
•