SUMMARY With a custom x-scheme-handler set in XDG, when the URL contain '=', link is always opened in default browser instead of link handler application. STEPS TO REPRODUCE 1. Install an application which adds a desktop file with a MimeType=x-scheme-handler/custom-handler. 2. Execute 'xdg-open custom-handler://key=value' (xdg-open is a script which actually passes the call to kde-open5 in KDE) OBSERVED RESULT Link opens in default browser. EXPECTED RESULT Link should be opened by application set to handle the custom scheme. With the "=" character removed from the link, the application opens as expected. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux 5.12.14, fully up-to-date KDE Plasma Version: 5.22.3 KDE Frameworks Version: 5.83.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION Details below are specific to my application, but bug seems to manifest for any custom handler when the link contains = character. For example you could try msteams://test vs msteams://te=st if you have MS Teams installed. Install EObcanka (Czech national ID card client application from AUR (or deb is available here https://info.eidentita.cz/Download/). This creates /usr/share/applications/eopauthapp.desktop with contents: [Desktop Entry] Name=eObčanka Identifikace Comment=Elektronická identifikace občanským průkazem Version=1.0 Type=Application Exec=/opt/eObcanka/Identifikace/eopauthapp.sh %u Path=/opt/eObcanka/Identifikace Icon=eopauthapp Terminal=false Categories=Qt;Utility; MimeType=x-scheme-handler/czeeopauth Keywords=eop;smartcards Ensure that 'xdg-mime query default x-scheme-handler/czeeopauth' returns eopauthapp.desktop. Then try 'xdg-open czeeopauth://mwid=1'. Opens in default browser. Compare with 'xdg-open czeeopauth://mwid1' (without the =). Opens cor using eopauthapp client application.
= is a reserved character in URL spec: https://datatracker.ietf.org/doc/html/rfc3986#section-2.2 %3d instead should work
I see your point. Unfortunately I am not the author of the problematic application, merely a user. The application is the client of the Czech national ID authority for citizens to authorise themselves when using eGovernment services. I will try to inform them. However we're talking public sector here, I'm not holding my breath (though they may surprise). However, I would also opine that with a custom scheme handler application, it should be up to the client application itself to determine the validity of the URI after the scheme:// part. Yes, this application doesn't conform to the RFC, but an alternative viewpoint is the kde-open/kioclient shouldn't care after it has determined that the (invalid) URI is handled by a special application. Just pass the URI to the application and let that worry about it. For information, this problem makes the Czech eGovernment application unusable for Chromium based browsers (i.e. all the main ones except Firefox) which use xdg-open to handle custom schemes. Workaround is to use Firefox of course (which uses it's own built is custom scheme handling which works fine despite the invalid URI) or hack xdg-open to call its open_generic function (also works fine) instead of open_kde when it recognises we're in KDE. Neither workaround is very satisfactory.
I just came here to report the same issue. It gets even funnier than that: czeeopauth://mwid=767aae75 -> kde-open5 changes scheme to http and passes it back to the browser (BAD) czeeopauth:/mwid=767aae75 -> correct app launched czeeopauth://mwid767aae75 -> correct app launched czeeopauth:mwid=767aae75 -> correct app launched Please note that using %3d instead of the = sign does NOT fix the problem. kde-open5 turns the original URL into something like "http://czeeopauth/mwid=767aae75". I seriously don't think that's a behavior defined by the RFC. This is definitely a bug (still present in 5.23.4).