Desktop: Fixes #6211: Try to replace the external link with internal link when attachment file is pasted in Markdown editor

[wh201906]

This will fix #6211. When the user copies an image from WYSIWYG editor, the clipboard will hold the absolute path of the image. The bug is when pasting it to Markdown editor, the absolute path will be pasted. Codes in this PR will try to replace the absolute path with the internal link if possible, just like copying and pasting an image in WYSIWYG editor. I tested it on Ubuntu and the bug is fixed. I have no idea about how to call an async function in an sync function. I just imitated the existing code. Please tell me if my code is wrong or not appropriate and I will fix it.

[wh201906]

~~I think editorPasteText() should run editorRef.current.replaceSelection(clipboard.readText()) if the replaceResourceExternalToInternalLinks() returns an empty string or "promise gets rejected". But I don't know how to implement this.~~ The async function replaceResourceExternalToInternalLinks(body, options) just replace the specified text in body, so there is no need to add extra code to handle the empty result. Also, this function doesn't throw errors, and it doesn't call other async functions, so the promise is always resolved.

[wh201906]

I don't know why the mobile build in CI failed. I did build the desktop version on Ubuntu and it works.

Here are the logs for Main (ubuntu-latest)

2022-09-19T03:08:29.2443537Z [94m➤[39m [90mYN0000[39m: │ [38;5;173mroot[39m[38;5;111m@[39m[38;5;111mworkspace:.[39m [32mSTDOUT[39m [94m➤[39m [90mYN0000[39m: [38;5;214m[@joplin/app-mobile]:[39m [03:08:29] Starting 'encodeAssets'...
2022-09-19T03:08:29.2517417Z [94m➤[39m [90mYN0000[39m: │ [38;5;166m@joplin/[39m[38;5;173mapp-mobile[39m[38;5;111m@[39m[38;5;111mworkspace:packages/app-mobile[39m [31mSTDERR[39m [03:08:29] 'encodeAssets' errored after 172 ms
2022-09-19T03:08:29.2524888Z [94m➤[39m [90mYN0000[39m: │ [38;5;166m@joplin/[39m[38;5;173mapp-mobile[39m[38;5;111m@[39m[38;5;111mworkspace:packages/app-mobile[39m [31mSTDERR[39m [03:08:29] Error: ENOENT: no such file or directory, open '/home/runner/work/joplin/joplin/packages/app-mobile/tools/../pluginAssets/katex/fonts/KaTeX_SansSerif-Regular.woff2.base64.js'
2022-09-19T03:08:29.2526917Z [94m➤[39m [90mYN0000[39m: │ [38;5;166m@joplin/[39m[38;5;173mapp-mobile[39m[38;5;111m@[39m[38;5;111mworkspace:packages/app-mobile[39m [31mSTDERR[39m [03:08:29] 'build' errored after 59 s
2022-09-19T03:08:29.3598695Z [91m➤[39m YN0009: │ [38;5;166m@joplin/[39m[38;5;173mapp-mobile[39m[38;5;111m@[39m[38;5;111mworkspace:packages/app-mobile[39m couldn't be built successfully (exit code 1, logs can be found here: [38;5;170m/tmp/xfs-ecaa907d/build.log[39m)
2022-09-19T03:08:29.7358828Z [94m➤[39m [90mYN0000[39m: │ [38;5;173mroot[39m[38;5;111m@[39m[38;5;111mworkspace:.[39m [32mSTDOUT[39m [94m➤[39m [90mYN0000[39m: [38;5;214m[@joplin/app-mobile]:[39m [03:08:29] Finished 'encodeAssets' after 491 ms

Here are the logs for ServerDockerImage (ubuntu-latest)

2022-09-19T03:07:12.8879815Z [94m➤[39m [90mYN0000[39m: │ [38;5;166m@joplin/[39m[38;5;173mapp-mobile[39m[38;5;111m@[39m[38;5;111mworkspace:packages/app-mobile[39m [32mSTDOUT[39m [03:07:12] Starting 'encodeAssets'...
2022-09-19T03:07:12.9020328Z [94m➤[39m [90mYN0000[39m: │ [38;5;173mroot[39m[38;5;111m@[39m[38;5;111mworkspace:.[39m [32mSTDOUT[39m [94m➤[39m [90mYN0000[39m: [38;5;214m[@joplin/app-mobile]:[39m [03:07:12] 'encodeAssets' errored after 122 ms
2022-09-19T03:07:12.9029337Z [94m➤[39m [90mYN0000[39m: │ [38;5;173mroot[39m[38;5;111m@[39m[38;5;111mworkspace:.[39m [32mSTDOUT[39m [94m➤[39m [90mYN0000[39m: [38;5;214m[@joplin/app-mobile]:[39m [03:07:12] Error: EEXIST: file already exists, mkdir '/home/runner/work/joplin/joplin/packages/app-mobile/pluginAssets/katex/fonts'
2022-09-19T03:07:12.9040022Z [94m➤[39m [90mYN0000[39m: │ [38;5;173mroot[39m[38;5;111m@[39m[38;5;111mworkspace:.[39m [32mSTDOUT[39m [94m➤[39m [90mYN0000[39m: [38;5;214m[@joplin/app-mobile]:[39m [03:07:12] 'build' errored after 55 s
2022-09-19T03:07:12.9816960Z [94m➤[39m [90mYN0000[39m: │ [38;5;173mroot[39m[38;5;111m@[39m[38;5;111mworkspace:.[39m [32mSTDOUT[39m [94m➤[39m [90mYN0000[39m: [38;5;214m[@joplin/app-mobile]:[39m Process exited (exit code 1), completed in 1m 2s
2022-09-19T03:07:12.9822495Z [94m➤[39m [90mYN0000[39m: │ [38;5;173mroot[39m[38;5;111m@[39m[38;5;111mworkspace:.[39m [32mSTDOUT[39m [91m➤[39m YN0000: The command failed for workspaces that are depended upon by other workspaces; can't satisfy the dependency graph
2022-09-19T03:07:12.9829183Z [94m➤[39m [90mYN0000[39m: │ [38;5;173mroot[39m[38;5;111m@[39m[38;5;111mworkspace:.[39m [32mSTDOUT[39m [91m➤[39m YN0000: Failed with errors in 1m 4s
2022-09-19T03:07:13.1364868Z [94m➤[39m [90mYN0000[39m: │ [38;5;173mroot[39m[38;5;111m@[39m[38;5;111mworkspace:.[39m [31mSTDERR[39m [03:07:13] 'build' errored after 1.12 min
2022-09-19T03:07:13.1365889Z [94m➤[39m [90mYN0000[39m: │ [38;5;173mroot[39m[38;5;111m@[39m[38;5;111mworkspace:.[39m [31mSTDERR[39m [03:07:13] Error: Command failed with exit code 1: yarn run buildSequential

They all have the similar errors when doing encodeAssets in the building process of app-mobile, but I didn't touch the code in app-mobile. Maybe we need to re-run the jobs

[laurent22]

We need a clear description of what's been fixed, and a working pr.

[wh201906]

We need a clear description of what's been fixed, and a working pr.

I have updated the title and description of this PR. Are they correct? I think the PR is working now since it passed all CI test, and I have tested the functionality of it on Ubuntu and it works as expected.

[wh201906]

@laurent22 Hi. Is there anything I need to do?

[laurent22]

Thanks for fixing this, and I think that's the right fix, but I wonder if we want to support this kind of copy and paste between wysiwyg and markdown editor? Lots of other things probably don't work, such as copying tables, and it feels like the solution is simply to not do it.

Why would someone want to copy from one editor to another anyway? Why not stay on the same one?

[wh201906]

but I wonder if we want to support this kind of copy and paste between wysiwyg and markdown editor?

I guess this PR can be applied to more situations. Any external links referring to something in profile(resources) directory can be converted into the internal links.

Lots of other things probably don't work, such as copying tables

I don't know why these things won't work after merging this PR. Could you please give me more information or examples? Plus, this PR is based on the behaviors of TinyMCE editor, as I mentioned in this comment. If something doesn't work there, the TinyMCE editor should have the similar problem.

[wh201906]

Another solution is to find the resource parts in the clipboard which look like [...](...), then replace them only.

[tomasz1986]

Why would someone want to copy from one editor to another anyway? Why not stay on the same one?

I mainly use WYSIWYG, but I also switch between the two when I want to add formatting that isn't available in the top bar (e.g. H4/5/6 or straight-up HTML code), and if I happen to have an image that I want to insert copied to clipboard already, I may as well paste it in the Markdown editor as well.

The main problem here is probably that the non-technical user isn't really aware that such a link is absolute and device specific. With tables and other complex formatting, the user can immediately see when something isn't right. With these images, it's only after they've synced their data to another machine when they discover that the links are broken. In the worst case scenario, at that point they may not even have the original images anymore.

[wh201906]

I think this problem is easier to be triggered than we expected. https://discourse.joplinapp.org/t/why-is-github-issues-long-left-to-be-answered/25993 https://discourse.joplinapp.org/t/disappearing-accessories-a-serious-functional-defect/28082 I'm willing to renovate this PR if the current version would cause any problem.

[tomasz1986]

I think this problem is easier to be triggered than we expected.

Yeah, and I think another aspect which hasn't been pointed enough yet is that this issue literally causes the user to lose data (e.g. when they no longer have access to the original device and/or file). The user who has lost data due to a bug is usually a very unhappy user.

[laurent22]

recheck

[github-actions[bot]]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[wh201906]

I have read the CLA Document and I hereby sign the CLA

[laurent22]

Ok let's merge, this change seems relatively safe and still an improvement. Thanks for implementing this @wh201906!