Custom URL's in entry preview panel are launched incorrectly

[Mr-Groch]

Expected Behavior

When URL field contains custom registered URL handler, for example rdp:// then system URL handler should be fired. It was working in 2.3.3 version.

Current Behavior

In 2.3.4 version double click on url starting with custom url like rdp:// does nothing.

Debug Info

KeePassXC - Wersja 2.3.4
Rewizja: 6fe821c

Biblioteki:

• Qt 5.11.1
• libgcrypt 1.8.3

System operacyjny: Windows 10 (10.0)
Architektura CPU: x86_64
Jądro: winnt 10.0.17134

Włączone rozszerzenia:

• Auto-Type
• Browser Integration
• Legacy Browser Integration (KeePassHTTP)
• SSH Agent
• YubiKey

[droidmonkey]

This was likely introduced with #1768. The fix may be related to what was done in #2311

[Niko-CZ]

This was likely introduced with #1768. The fix may be related to what was done in #2311

Is it possible to have "cmd://" to be considered as custom URL after correction and handled based on OS properties?
In this case Windows and MacOS may use "open URL" for same entry without any additional corrections. F.e. for putty on Windows standard URL will be:
cmd://putty.exe -ssh {NOTES} -X -l {USERNAME} -pw {PASSWORD}
On MacOS with dummy app handling "cmd://", it will be possible to choose related app based on cmd://app.
At the moment all URLs starting with "cmd://" are handled by browser and opened with "https://" prefix.

[droidmonkey]

cmd:// urls are not handled by the browser. See code around

keepassxc/src/gui/DatabaseWidget.cpp

Line 637 in 6fe821c

if (cmdString.startsWith("cmd://")) {

[Niko-CZ]

Not sure how does it work....
Please check 2 screenshots in attachments. First one is for 2.3.4. I have just showed what is opening.
Second one is from 2.3.3. In that version even URL showed in form of [https://], beside the fact that in item modification it is visible that it is in regular windows form [cmd://putty.exe -ssh {NOTES} -X -l {USERNAME} -pw {PASSWORD}].

[droidmonkey]

Yup that's a bug. When you click the link in the preview panel it opens the browser (this is because it is resolving the URL within the cmd to form the link in the first place). When you double click the URL field in the entry view, it properly executes the command. Captured in #2438.

[pmorch]

Linux workaround:

In linux xdg-open can launch standard and custom-registered URL-schemes. So in 2.3.3 a URL of:

my-scheme://{USERNAME}:{PASSWORD}@server

worked (if configured correctly in ~/.local/share/applications) but it doesn't in 2.3.4. The workaround in 2.3.4 is to use this URL instead:

cmd://xdg-open my-scheme://{USERNAME}:{PASSWORD}@server

( Is there any reason for not calling xdg-open on linux or open on macOS for every non-http/https/cmd URL and let it up the configuration of the desktop environment to open the correct browser/application? )

[droidmonkey]

That is the bug

[SohamG]

Should be fixed in #3153