1615370 - Launching URIs fails when explorer.exe is not running

Status: RESOLVED FIXED

(Firefox :: File Handling, defect, P3)

Description

[Koenig]

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

[:Gijs (he/him)]

: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...

Comment 2

[Toshihito Kikuchi [:toshi]]

I think we need to add a fallback in nsMIMEInfoWin::LoadUriInternal as we did for bug 1602726. I'll try it tomorrow.

Comment 3

[Toshihito Kikuchi [:toshi]]

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.

Comment 4

[Toshihito Kikuchi [:toshi]]

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

Comment 5

[Koenig]

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 :)

Comment 6

[Koenig]

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?

Comment 7

[Toshihito Kikuchi [:toshi]]

Attachment: Bug 1615370 - Add fallback to ShellExecuteExW in nsMIMEInfoWin. r=aklotz

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.

Comment 8

[Toshihito Kikuchi [:toshi]]

(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

[Jorg K (CEST = GMT+2)]

Kill Windows explorer and URI launch will stop working.

Just out of interest. How do you work when Windows Explorer isn't running?

Comment 10

[Koenig]

(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.

Comment 11

[Toshihito Kikuchi [:toshi]]

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.

Comment 12

[Koenig]

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

[Masatoshi Kimura [:emk]]

ShellExecute is implemented by in-process shell32.dll. Bug 1567614 (inheriting mitigation policies from the host process) happened for that very reason.

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/08488953cff8
Add fallback to ShellExecuteExW in nsMIMEInfoWin. r=aklotz

Comment 15

[Oana Pop-Rus]

https://hg.mozilla.org/mozilla-central/rev/08488953cff8

Comment 16

[Ryan VanderMeulen [:RyanVM]]

This sounds edge-case enough to not worry about uplifting to ESR. Feel free to nominate if you feel strongly otherwise.