Custom schemas may not work

Bug reports
1

Steps to reproduce

Links with custom schemas such as the following can no longer be opened using command+click.

[Open](<myapp:///Volumes/STORAGE/sample.zip>)

Expected result

Opens the file in the specified app.

Actual result

I get a “cannot open location” error.

Environment

SYSTEM INFO:
Obsidian version: v1.6.3
Installer version: v1.4.13
Operating system: Darwin Kernel Version 22.5.0: Thu Jun 8 22:29:35 PDT 2023; root:xnu-8796.121.3~8/RELEASE_ARM64_T6020 22.5.0
Login status: not logged in
Insider build toggle: off
Live preview: on
Base theme: adapt to system
Community theme: none
Snippets enabled: 0
Restricted mode: on

RECOMMENDATIONS:
none

Additional information

  • Versions prior to 1.5 will work.
  • If I click from the popup preview it works.
  • Clicking on a link from the Dataview plugin also works.
2

I am gonna need more details.

3

I am passing file paths to the app through a custom schema.
There’s something strange happening there.

  • Links work in the editor’s reading mode.
  • Links do not work in the editor’s source mode.
  • Links do not work in the editor’s live preview.
  • Links work in the popup preview.

(Use Command+Click for source mode, Click for others.)

Is it a bug that links behave differently in reading mode and live preview?

4

which link? can you provide an example.

Download and reinstall obsidian.

does this open in the sandbox vault

[Open](<file:///Volumes/STORAGE/sample.zip>)

EDITED typo.

5

Same result after reinstalling and running in sandbox.
I’ve tried a few things and discovered something very important.

OK
[Open](<myapp:///Volumes/STORAGE/FolderA/sample.zip>)

NG
[Open](<myapp:///Volumes/STORAGE/Folder A/sample.zip>)

It didn’t work if there were spaces in the file path.
But strangely enough, the following phenomenon also occurred:

OK
[Open](<file:///Volumes/STORAGE/Folder A/sample.zip>)

NG
[Open](<files:///Volumes/STORAGE/Folder A/sample.zip>)

The ‘file’ schema allowed spaces, but ‘files’ did not.

6

If it doesn’t open, the error message is:
cannot open location "myapp:///Volumes/STORAGE/Folder A/sample.zip"

When you hover over a clickable link, the tooltip appears as follows:
myapp:///Volumes/STORAGE/Folder%20A/sample.zip

So my guess is that the spaces aren’t properly URL encoded.

7

ok, this is not a bug.
You must URL encode urls when using markdown links

8

The explanation you provided seems to be about internal links.
Also, it doesn’t explain the different behavior between reading mode and live preview.

Is it possible to make it work the same as the previous version?

9

All standard markdown links must be url encoded (internal and external). This was always a requirement.
Non url-encoded markdown links are outside the spec.

10

There is also this description:

According to CommonMark1, you can use links with spaces as long as the URL is wrapped in angle brackets e.g.
[Link caption](<https://duckduckgo.com/?q=test this!&t=ffab>)

11

yes, you can use angle brackets

12

Yes, I think spaces should be allowed because we are using angle brackets.

13

angle brackets work for me.

14

Really? I tried it with the files schema and it didn’t work.

[Open](<files:///Volumes/STORAGE/Folder A/sample.zip>)
15

it’s file not files

16

Yes. As I commented before, for some reason only the file schema works. It doesn’t work with other schemas.

17

Does it not work with https?

18

https worked.

[Open](<https://www.google.co.jp/search?q=sample aaa>)

I don’t really understand the difference.

19

I’ll keep this open, let’s see if somebody else has this problem.

1 Like
20

I think I suffer this too, for me problem started with obs. 1.6.3. I’m pasting my report from elsewere:

I have lots of links of the form [text](<....>)

that were working up to now but then with the rolling out of 1.6.3 they are all broken. They contained spaces but they worked, now it seems that I have to url-encode all of them for them to continue working?

I tested with links to markdown file targets which seem ok, but in my case that maybe is not average use (i’m using custom protocol handlers), I’m seeing for certain that there has been a breaking change.

Example link [document](<lib:/dir/My Doc.pdf>)

where lib is the custom protocol.

  • former behavior: custom protocol handler invoked.
  • 1.6.3 behaviour: obsidian says “cannot open location …”

Url-encoding the link target then it works again
[document](<lib:/dir/My%20Doc.pdf>)

conclusion: I think links with angle brackets didn’t need url-encoding before, and in 1.6.3 that unexpectedly changed, and now old non-url-encoded links in angle brackets became broken.