fix(files): don't expose WebDAV XML-attribute artifacts as DOM attributes

[chrip]

Summary

Tagged office files (and other tagged files) cannot be opened in the Viewer on Firefox and Safari since Nextcloud 33. Opening them throws:

InvalidCharacterError: Invalid qualified name: '@canAssign'  (vue.runtime.esm.js)

Chrome is unaffected (it silently tolerates the invalid attribute name).

Originally reported against Nextcloud Office: nextcloud/richdocuments#5490 — but the crash is in the Viewer's genFileInfo, triggered for any tagged file.

Root cause

genFileInfo() (src/utils/fileUtils.ts) recursively flattens every DAV property and runs camelcase() on every key.

Since Nextcloud 33, a file's nc:system-tags PROPFIND property contains <nc:system-tag> elements that carry XML attributes (can-assign, id, user-visible, …) — see apps/dav/lib/SystemTag/SystemTagList.php in server. The WebDAV/fast-xml-parser layer represents those attributes with a leading @ (e.g. @can-assign), and camelcase('@can-assign') preserves the leading @, yielding @canAssign.

genFileInfo therefore produces a key @canAssign on the file-info object. Viewer.vue binds that object with v-bind="currentFile", so Vue calls el.setAttribute('@canAssign', …). @ is illegal in a DOM/XML qualified name → Firefox & Safari throw, Chrome ignores it.

The server XML is valid; the bug is purely in the client-side flattening.

Fix

In genFileInfo:

• Skip the structured system-tags subtree — it is not scalar file metadata and should not be flattened into the file-info object.
• Defensively drop any camelCased key that still starts with @, so WebDAV XML-attribute artifacts can never reach the DOM.

Testing

Validated with a faithful reproduction of genFileInfo's logic + the real camelcase@8 package against a webdav-parsed PROPFIND of a tagged file:

Case	before	after
Single tag	emits @canAssign, @id, @userVisible → setAttribute throws	gone, no invalid keys
Multiple tags	leaks systemTag array as attr	clean
Real metadata (fileid, filename, …)	preserved	still preserved

To reproduce manually: tag any office file, open it in Firefox → console InvalidCharacterError on master, gone with this change.

Notes

• Compiled assets under js/ are not included (my local toolchain is Node 22 / npm 10, the repo requires Node ^24 / npm ^11). Please recompile via CI / the compile bot.

Ref: nextcloud/richdocuments#5490

Assisted-by: ClaudeCode:Opus-4.8

[szaimen]

@skjnldsv can you please review this? I fear I dont have enough knowledge on this part of the code to be able to do so myself.

[github-actions]

Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

(If you believe you should not receive this message, you can add yourself to the blocklist.)

[moodyjmz]

@skjnldsv Hiya, would you be able to review this?