laurent22 / joplin

Joplin - the privacy-focused note taking app with sync capabilities for Windows, macOS, Linux, Android and iOS.
https://joplinapp.org
Other
46k stars 5k forks source link

Local file URLs with parameters don't work. #6176

Open tmfelwu opened 2 years ago

tmfelwu commented 2 years ago

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)
  2. Try to open the link.
  3. 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 commented 2 years ago

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).

laurent22 commented 2 years ago

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.

tmfelwu commented 2 years ago

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

Manish4044 commented 2 years ago

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

I think he meant about the URL utilities function calls.

laurent22 commented 2 years ago

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

yes

github-actions[bot] commented 2 years ago

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] commented 2 years ago

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.

personalizedrefrigerator commented 7 months ago

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