electron
electron copied to clipboard
electron
shell.openExternal uses wrong application
Issue Details
- Electron Version:
- 11.0.0-beta.20
- Operating System:
- Windows 10 19041
- Last Known Working Electron version:
- None
Expected Behavior
I have "Directory Opus" (https://www.gpsoft.com.au/) installed as a file explorer replacement. When I call shell.openExternal with a folder/directory path it should open in Opus.
Actual Behavior
The regular Windows Explorer opens.
To Reproduce
To be honest I don't know where you configure which application Windows uses by default to open directories so to reproduce I guess install Directory Opus and use shell.openExternal("C:") ?
Additional Information
Both https://github.com/sindresorhus/open and the native ShellExecuteEx work as expected and open Directory Opus.
This doesn't seem like an Electron bug. You would need to change the default file explorer app to be yours and then I'd expect openExternal will use the right application. Here's at least one idea for how to do that though for Win7
I did a little initial digging, it looks like shell.openExternal() resolves down to ShellExecuteW @ https://github.com/electron/electron/blob/master/shell/common/platform_util_win.cc#L236 which uses whatever application is registered for the given URL as per the registration info in https://docs.microsoft.com/en-us/windows/win32/shell/app-registration ., but I haven't tried installing Directory Opus to reproduce this issue.
My guess is that @pushkin- is right that this is an issue with Opus not being registered correctly. @TanninOne could you try that and report back if the issue persists?
If that doesn't resolve it -- the next step after that @TanninOne would you be to provide how you're invoking ShellExecuteEx, because I'm trying to understand why ShellExecute and ShellExecuteW are producing different results on your setup. @TanninOne
Ok, I have further information @ckerr
It is true that openExternal, under the hood, calls ShellExecute as well, but it manipulates the parameters before it does so.
when you run shell.openExternal('c:\') in electron, the api call looks like this (debugged with API Monitor):
ShellExecuteA(NULL, "open", "\"file:///C:/\"", NULL, NULL, SW_SHOWNORMAL);
So it adds file:// to the path and adds quotes around the file name. From my testing with the native API both of those modifications do change the behavior of ShellExecute.
Considering that electron behaves differently from other native tools and node-open with no option to disable the quoting I would argue that this is in fact a bug because it is very much unexpected and not fixable in client code.
Why it behaves differently because of some quoting I can not say though.
Some more information, about why this may be happening. I posted a question about this issue to this directory opus forum thread and the directory opus developer responded with a suggested fix to the Electron call:
It's not the quoting that's causing the problem.
The problem there is that they are explicitly asking for the "open" verb, which will run Explorer. (From memory, if we changed what that did in the registry, it'd break double-clicking folders within Explorer, or make them open in Opus, which is undesirable. It'd also make turning off Explorer Replacement a lot more error prone, especially on a system with more than one third-party file manager, since the original verb could get lost in multiple renames.)
They should instead set the second argument to NULL, which makes ShellExecute use the default verb. If Explorer Replacement is turned on, we make "openindopus" the default verb, but that shouldn't be used explicitly either. Just set the verb to NULL and let the system take care of it.
Some more information, about why this may be happening. I posted a question about this issue to this directory opus forum thread and the directory opus developer responded with a suggested fix to the Electron call:
It's not the quoting that's causing the problem. The problem there is that they are explicitly asking for the "open" verb, which will run Explorer. (From memory, if we changed what that did in the registry, it'd break double-clicking folders within Explorer, or make them open in Opus, which is undesirable. It'd also make turning off Explorer Replacement a lot more error prone, especially on a system with more than one third-party file manager, since the original verb could get lost in multiple renames.) They should instead set the second argument to NULL, which makes ShellExecute use the default verb. If Explorer Replacement is turned on, we make "openindopus" the default verb, but that shouldn't be used explicitly either. Just set the verb to NULL and let the system take care of it.
That is not what I'm seeing on my system. If I call ShellExecuteEx directly with the "open" verb and without the quoting it does open in Directory Opus. Add either the quotes or the file:// protocol and it opens in explorer.
This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. If you have any new additional information—in particular, if this is still reproducible in the latest version of Electron or in the beta—please include it with your comment!
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. If you have any new additional information—in particular, if this is still reproducible in the latest version of Electron or in the beta—please include it with your comment!
This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. If you have any new additional information—in particular, if this is still reproducible in the latest version of Electron or in the beta—please include it with your comment!
This issue has been closed due to inactivity, and will not be monitored. If this is a bug and you can reproduce this issue on a supported version of Electron please open a new issue and include instructions for reproducing the issue.