fix: migrate to @nextcloud/viewer 2 and Vue 3

[juliusknorr]

• Resolves: Fixes Migrate off the OCA.Viewer global before Nextcloud 36 #6060
• Target version: main

Summary

Port off the removed OCA.Viewer global (nextcloud/server#63954):

• Bump to Vue 3, @nextcloud/vue 9, @nextcloud/dialogs 7 and @nextcloud/viewer 2 (beta)
• Register the viewer handler as a richdocuments-viewer custom element with enabled(nodes)
• Open files via getViewer().open() (file actions, public share, "continue editing online")
• Load the handler on BeforeTemplateRenderedEvent instead of LoadViewer

Known limitation: no "Compare to current version" for office files

On server master the versions tab only offers compare for images, see FilesVersionsSidebarTab.vue#L120-L127, because @nextcloud/viewer had no canCompare handler flag. The comparison itself works with this PR (getViewer().compare() shows current and old version side by side).

To fix, once nextcloud-libraries/nextcloud-viewer#94 is released (after 2.0.0-beta.14):

• server: replace the mime check with canCompare(node) from @nextcloud/viewer
• here: bump @nextcloud/viewer and set canCompare: true in registerHandler() in src/init-viewer.js

TODO

• Opening a document from Files, closing it
• Opening an old version (read-only), comparing via getViewer().compare()
• Public link share: guest name dialog, then editing
• Admin settings (toggles, allow list, group select) and personal settings (template folder picker)
• Reference picker: file picker, section list, generated link opens the document. Tested by mounting the picker element directly, as Text on server master does not open files with the new viewer yet
• Set canCompare once the viewer release is out (see above)

The new viewer remounts a handler on every files:node:updated for the file it shows, which reloaded the document on each save. The editor now holds that event back until it closes, so the files list updates its modification time on close. A handler flag in @nextcloud/viewer to opt out of the reload would be the cleaner fix.

Expected CI failures from other apps on server master, not this PR:

• talk.spec.js: Talk still calls OCA.Viewer.registerHandler
• open.spec.js "Open PDF with files PDF viewer": files_pdfviewer registers no viewer handler on master yet

share-link.js now reopens the folder instead of reloading, as server master does not serve the /s/{token}/{fileid} URLs the files app navigates to on public shares.

Not changed here: src/public.js reads hidden inputs (#mimetype, #hideDownload) that public share pages no longer render, so its PDF special case does nothing on current servers. Documents on shares still open through the Files app.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Documentation (manuals or wiki) has been updated or is not required

[elzody]

Scared me at first when I saw the line diff. Luckily, most of it is from updating package-lock.json. Otherwise, looks good. Started looking into the problems with viewer in the failing Cypress tests, and it led me here. :)

Was going to suggest a more logical separation in terms of migrating to Vue 3 and then doing the migration to @nextcloud/viewer, accepting failures on main until then (as we do now), but I guess why not do them both at once.

[juliusknorr]

Was going to suggest a more logical separation in terms of migrating to Vue 3 and then doing the migration to @nextcloud/viewer, accepting failures on main until then (as we do now), but I guess why not do them both at once.

The problem is that then we would build vue 3 compatible version that we could not test without an older server commit or only against stable33. I feel reasonably comfortable with doing both changes also considering CI is mostly happy (except for the mentioned cases).

[elzody]

Looks pretty good after taking a look through things manually. A review with Claude revealed the following that might be interesting to double check.

The viewer keeps richdocument's component hidden until it emits loaded, which is only emitted after Collabora's iframe reports back; so if an error were to occur before that then it's possible the viewer will be stuck loading while the failure is hidden and the viewer keeps spinning. I don't have a good answer for that, but maybe we could do something with the viewer's errored event.

A smaller nitpick would be to guard BeforeTemplateRenderedEvent against loading the viewer on an error page rendering since documents can't be opened there. Other apps do this too:

if ($event->getResponse()->getRenderAs() === TemplateResponse::RENDER_AS_ERROR) {
    return;
}

[juliusknorr]

Thanks, I'll check on those

[juliusknorr]

@elzody Thanks, both fixed: any loading failure, now including a failed token request, reports the editor as loaded so the viewer shows our error screen instead of spinning (loaded rather than errored keeps our more detailed error message), and the listener now skips error pages.