Checks before filing an issue

• This issue doesn't reproduce on web browsers (such as in Chrome). If it does, issue reports go to the Mattermost Server repository.
• I have checked the issue tracker and have not found an issue that matches the one I'm filing. This should include closed issues.
• This issue is not a troubleshooting question. Troubleshooting questions go here: https://forum.mattermost.com/c/trouble-shoot/16.
• This issue is not a feature request. You can request features and make product suggestions here: https://mattermost.com/suggestions/.
• This issue reproduces on the most recent stable version, or the most recent prerelease version of the Mattermost Desktop App.
• I have read the contribution guidelines.

Mattermost Desktop Version

5.13.1

Operating System

Windows 10

Mattermost Server Version

10.11.3

Steps to reproduce

Copy a Microsoft OneNote (classic offline version) link - specifically a deep link that references a certain page or paragraph - using the OneNote context-menu "Copy Link to Page"/Paragraf.
You don't need OneNote to reproduce this. Just go with my hypothetical examples below.

Paste the clipboard in a plain text editor. See something like this:
onenote:///D:\OneNote\Apps\Mattermost.one#Schöne%20neue%20Seite&page-id={840EDD0C-B6FB-481E-A342-E39AEDA50EE6}
Note the windows path delimiter backslashes.
Note that OneNote did URL-encode the spaces, but not the umlaut nor the curly brackets.
Note that the URI does not contain a ?query, and the #fragment part is not rightmost.
It looks all wrong, but it is valid in Windows/OneNote.

Paste the link in Mattermost, yielding this markdown:
[Schöne neue Seite](onenote:///D:/OneNote/Apps/Mattermost.one#Schöne%20neue%20Seite&page-id={840EDD0C-B6FB-481E-A342-E39AEDA50EE6})
Notice the backslashes became regular (forward) slashes.
This is because the clipboard has an HTML formatted verison, that essentially contains a regular link with exactly this text and URI.

Also paste the previously seen plaintext version.
onenote:///D:\OneNote\Apps\Mattermost.one#Schöne%20neue%20Seite&page-id={840EDD0C-B6FB-481E-A342-E39AEDA50EE6}

Expected behavior

Clicking these links should pass the URL to Windows' shell, causing OneNote to start and jumping to the referenced section/page/paragraph.

Observed behavior

Clicking the first markdown link opens an error pop-up: "Invalid Link"
"The link you clicked appears to be malformed and cannot be opened. Please check the URL for errors before trying again."

With the text-only link, nothing visibly happens at all.

Log Output

The markdown link click logs as:
`[TAB_MESSAGING] Ignoring invalid URL: onenote:///D:/OneNote/Apps/Mattermost.one#Sch%C3%B6ne%20neue%20Seite&page-id={840EDD0C-B6FB-481E-A342-E39AEDA50EE6}`

The plain link logs as:
`[TAB_MESSAGING] Ignoring non-url onenote:///D:\OneNote\Apps\Mattermost.one#Sch%C3%B6ne%20neue%20Seite&page-id={840EDD0C-B6FB-481E-A342-E39AEDA50EE6}`

Additional Information

Both links can be transformed to work by replacing the back- with forward slashes (Windows mostly accepts both, nowadays), and the curly braces {/} with %7b/%7d. But omitting those also works. Things get weird there.

OneNote even still finds the right page, when either the #page-title or the &page-id part of the URI is removed.
This last case, however, does not work reliably in Mattermost, as it works in UTF-8 and URL-encodes links? So when it passes a string like Sch%c3%b6ne (instead of decoded Schöne) to the Windows shell, OneNote takes that literally and won't find the page.

Mattermost should probably
a) Not be smart about RFC 3986 voilating URI schemes, or onenote: at least.
b) URL-decode onenote: links before passing them to the Windows shell.

I like to pretend that this should even work mostly fine if the system locale is not UTF-8.
And that it won't have gruesome security implications, since other users input gets passed to the friggin shell.