[stable31] Fix/hide link decoration in read-only mode#8257
[stable31] Fix/hide link decoration in read-only mode#8257silverkszlo merged 1 commit intostable31from
Conversation
Fixes issue where link preview options and delete button were accessible in read-only shares, causing confusion as changes didn't persist. Check editor.options.editable before returning decorations to ensure PreviewOptions are never rendered when the editor is not editable. Signed-off-by: silver <s.szmajduch@posteo.de>
mejo-
left a comment
There was a problem hiding this comment.
Code changes look sensible to me. I didn't test myself but guess you did so.
Small remark: I wonder whether it would be better to simply not load the previewOptions plugin in the Tiptap paragraph node if editor is read-only, but guess that would be more complicated to implement in a way that it is reactive in a way that it takes into account if the editor becomes editable/non-editable after being initialized.
Given that it's a fix for a stable release that will become EOL soon, I'd not spend too much energy into optimizing this 😉
Thank you! I'll merge that for now so that it gets into the upcoming release. I can refactor later on if we want that :) |
📝 Summary
Note: This bug only happens in Nextcloud 31 and already has been fixed in NC 32.
Problem
When a Text file is shared in read-only mode, users can access and interact with link preview options (toggle preview mode, delete link, open in new tab). Changes appear to work but don't persist after reopening the file, creating a confusing UX.
Solution
Fixed the
previewOptionsplugin to checkeditor.options.editableat the beginning of theapply()function, before checking if the document changed. This ensures decorations (and thus the PreviewOptions component) are never created when the editor is read-only.🏁 Checklist
npm run lint/npm run stylelint/composer run cs:check)