joplin icon indicating copy to clipboard operation
joplin copied to clipboard

Local file URLs with parameters don't work.

Open tmfelwu opened this issue 2 years ago • 8 comments

Description

I am trying to open a pdf to a certain page via link to local files. Say I have a pdf at /home/abc/file.pdf

In markdown this works fine as it should.

 [File](file://home/abc/file.pdf)

However, when I try to specify the page number

 [File](file://home/abc/file.pdf#page=4)

Nothing happens. On seeing the journalctl logs I see this error.

Feb 19 01:13:08 appimagekit-joplin.desktop[7182]: gio: file:////home/abc/file.pdf%23page=4: Error when getting information for file “//home/abc/file.pdf#page=4”: No such file or directory

I have tried to URL encode the path, like so

 [File](file://home/abc/file.pdf%23page%3D4)

but this still doesnt work.

Shouldn't it (i think electron handles this) just check for the existence of file://home/abc/file.pdf instead of file://home/abc/file.pdf#page=4

Environment

Joplin version: 2.7.12 Platform: Linux OS specifics: Ubuntu 18.04

Steps to reproduce

  1. Create a note with the following text
 [File](file://home/abc/file.pdf#page=4)
  1. Try to open the link.
  2. The link doesnt work. Nothing happengs.

Describe what you expected to happen

The pdf should open at the correct page number.

Logfile

useMessageHandler.ts:16 Got ipc-message: file:////home/abc/file.pdf#page=3 null
Logger.ts:219 06:49:17: CommandService::execute: openItem file:////home/abc.pdf#page=3

No error messages.

Diagnosis

I think these lines might be the reason.

Is there a reason we are using openPath for files instead of openExternal whose argument is URL.

tmfelwu avatar Feb 19 '22 01:02 tmfelwu

Turns out it is because we are using the path instead of the uri when the resource starts with file://. Switching to shell.openExternal() and passing the uri instead of the path at this place works fine (atleast on linux).

tmfelwu avatar Feb 19 '22 14:02 tmfelwu

If you check the history of this file you'll see we switched between openExternal and openPath many times. Basically every time someone has an issue like yours they create a PR to switch the call, which makes one case works and break other cases. Supporting the hash symbol is low priority although if you manage to fix it without changing the function call we could consider it.

laurent22 avatar Feb 19 '22 14:02 laurent22

@laurent22 just to confirm do you mean without changing shell.openPath to shell.openExternal?

tmfelwu avatar Feb 20 '22 06:02 tmfelwu

@laurent22 just to confirm do you mean without changing shell.openPath to shell.openExternal?

I think he meant about the URL utilities function calls.

Manish4044 avatar Feb 20 '22 07:02 Manish4044

@laurent22 just to confirm do you mean without changing shell.openPath to shell.openExternal?

yes

laurent22 avatar Feb 20 '22 09:02 laurent22

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may comment on the issue and I will leave it open. Thank you for your contributions.

github-actions[bot] avatar Mar 23 '22 16:03 github-actions[bot]

Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, feel free to create a new issue with up-to-date information.

github-actions[bot] avatar Mar 30 '22 16:03 github-actions[bot]

Still an issue. See https://discourse.joplinapp.org/t/linking-anomaly/37506/2