feat(web-app-html-editor): add an HTML editor with live preview

[dj4oC]

Summary

Adds a new core app, web-app-html-editor, that opens .html / .htm / .xhtml
files in a CodeMirror 6 source editor with a live, sandboxed preview. No WOPI and no
extra server: the file is loaded and saved over WebDAV by the standard AppWrapper,
the source is edited in CodeMirror, and the rendered result is shown in a strictly
sandboxed <iframe srcdoc>.

Approach

The app is intentionally thin and idiomatic. It mirrors web-app-text-editor:
defineWebApplication registers it by file extension and routes through
AppWrapperRoute. By declaring a currentContent prop and emitting
update:currentContent, it inherits the framework's WebDAV load/save, dirty
tracking, Ctrl+S, autosave, the unsaved-changes guard and error notifications, so
none of that is reimplemented. The app itself only composes:

• HtmlEditorPane.vue - a CodeMirror 6 wrapper (HTML mode, line numbers, theme
  follows the active ownCloud theme). CodeMirror 6 is already in the workspace via
  md-editor-v3, so the individual @codemirror/* packages are added at the
  versions already in the lockfile.
• HtmlPreviewPane.vue - a sandboxed srcdoc iframe.
• HtmlToolbar.vue - an Editor | Split | Preview view-mode toggle (CSS grid; the
  filename, Save and action menu come from AppTopBar).

The app is enabled by default via the apps array in config/config.json.dist and
config/config.json.sample-ocis.

Security

The preview renders attacker-influenceable HTML (a user may open a file shared to
them), so the preview is treated as untrusted:

• The iframe uses sandbox="allow-scripts" with no allow-same-origin (opaque
  origin), so the preview cannot read the shell's cookies, storage or OIDC token,
  cannot call the oCIS API as the user, and cannot script the parent. allow-forms
  and allow-popups are deliberately omitted.
• A strict CSP (default-src 'none'; form-action 'none'; base-uri 'none'; inline
  script/style and data:/blob: only) is injected into the srcdoc, so the
  preview is network-isolated and does not depend on the deployment proxy CSP.
• The live preview is paused for very large files until the user opts in, so a huge
  or hostile document cannot freeze the tab on open.
• A regression test pins the exact sandbox contract (token set + srcdoc-not-src).

Trade-off: because the preview is network-isolated, documents that reference
external stylesheets/scripts/images will not load them. This is intentional for
a first version. The package ships ARCHAEOLOGY.md, DECISIONS.md and
SECURITY-REVIEW.md documenting the design rationale and the threat model.

Testing

• Unit tests (vitest): app wiring, the CodeMirror pane, the preview pane (sandbox
  contract, srcdoc), the toolbar, the CSP-injection helper, and the large-file
  preview pause. pnpm --filter html-editor test:unit is green (27 tests).
• vue-tsc --noEmit, eslint and prettier are clean.
• Verified manually against a running oCIS 8.0.4: opening a .html file (the app is
  picked up as the default opener), live edit updating the preview, and saving back
  over WebDAV.

Notes

• Registration is by file extension (oCIS associates apps to files by extension, not
  MIME type), matching web-app-text-editor.
• No drag-to-resize split handle in this version (kept simple).

[update-docs]

Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes.

[kw-security]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[LukasHirt]

Is this the correct location or should it live rather in the web-extensions repo?

[dj4oC]

Is this the correct location or should it live rather in the web-extensions repo?

If we move this to web-extensions, we need to move md-editor as well. Same stuff is reused in here

[LukasHirt]

[Security — High] The regex /<head\b[^>]*>/i matches the first occurrence of <head anywhere in the document, including inside HTML comments. A document like:

<!-- <head> -->
<html><head><title>X</title></head>...

causes .replace() to inject the CSP <meta> into the comment (which the browser ignores), while the real <head> element receives no CSP injection. The preview iframe then renders the hostile document with default-src 'none' and form-action 'none' unenforced — defeating the defense-in-depth layer.

The same applies to the /<html\b[^>]*>/i branch at line 41.

Fix: strip HTML comments before testing, or use a parser instead of regex to locate the insertion point.

[LukasHirt]

[Security — High] renderLargeAnyway is set to true in showPreviewAnyway() but is never reset. After a user opts in once for a large file, any subsequent change to currentContent — including a conflict-reload that replaces the file with an attacker-controlled version — immediately calls schedulePreview() without going through the pause gate, because this watch condition evaluates to false.

A realistic path: user clicks 'Show preview anyway' on a 600 KB file → attacker updates the file via a concurrent write → AppWrapper detects a 412 conflict and reloads → the watch fires with the new (still large, now hostile) content → renderLargeAnyway.value === true → preview renders automatically, no prompt.

Fix: reset renderLargeAnyway.value = false at the top of the watch handler (before the early-return check) so each new content version starts paused.

[LukasHirt]

[Bug — Medium] The early-return path for large content sets previewContent.value = '' but does not cancel the pending previewTimer. If a timer was queued from a previous small-content update, it fires up to 250 ms later and writes stale HTML back into previewContent, restoring an old preview snapshot even though the pause gate is active.

Sequence:

1. User types; schedulePreview() queues a 250 ms timer with snapshot S.
2. User pastes a large block; watch fires, sets previewContent = '', returns early — timer is still live.
3. Timer fires → previewContent = wrapWithPreviewCsp(S) (stale snapshot re-appears).
4. User clicks 'Show preview anyway' → sees stale content for up to 250 ms instead of the actual current document.

Fix: call clearTimeout(previewTimer) (and set previewTimer = undefined) before returning early.

[LukasHirt]

[Bug — Medium] showPreviewAnyway() sets renderLargeAnyway.value = true synchronously, which immediately flips the v-if/v-else in the template so <html-preview-pane> mounts. At that moment previewContent.value is still '' (it was cleared by the watch's early-return path), so the iframe receives srcdoc="" — an empty, CSP-less page — and the user sees a blank preview for up to 250 ms until the schedulePreview timer fires.

Fix: call schedulePreview synchronously and await nextTick() before flipping renderLargeAnyway, or set previewContent to the wrapped value synchronously inside this function (skipping the debounce for this one explicit opt-in action).

[LukasHirt]

[Bug — Minor] The initial previewContent is computed synchronously at setup time, bypassing the watcher and the 250 ms debounce. Subsequent external content changes (e.g. a conflict-reload updating the currentContent prop) go through schedulePreview and arrive 250 ms later. This creates a structural inconsistency: the initial render is immediate, but every prop update after that is delayed.

In practice this means a user who saves the file from another tab and triggers a conflict-reload will see the editor pane update instantly while the preview pane lags by 250 ms — a momentary split-brain state that could look like a failed save.

Consider routing the initial render through schedulePreview as well (or using schedulePreview with a 0 ms delay for the initial case) so the two paths are identical.

[LukasHirt]

[Bug — Minor] The watch source is () => isDark(), but isDark() is a plain function that reads themeStore?.currentTheme via optional chaining. When themeStore is undefined (as it is under vi.mock('@ownclouders/web-pkg')), the getter has no reactive dependencies to track, so the watcher never fires in tests. Any regression that breaks dark-mode theme switching in the editor passes the full test suite silently — the watch path is structurally untested.

In production the watcher works because themeStore is always defined, but the tested and production code paths diverge structurally. This is related to the test-accommodation issue at line 39.

[LukasHirt]

[Cleanup] The condition isPreviewTooLarge(value) && !renderLargeAnyway.value here duplicates the previewPaused computed defined at line 73. If the pause logic ever gains a third flag, the watch body must be updated separately and the two can silently diverge.

Consider replacing with previewPaused.value to keep a single source of truth for what 'paused' means.

[LukasHirt]

[Cleanup] The themeStore?.currentTheme optional-chaining guard was added to survive vi.mock('@ownclouders/web-pkg') returning undefined in tests — a test-accommodation that leaks into production code. Every other consumer of useThemeStore in the monorepo (e.g. web-pkg/src/components/TextEditor/TextEditor.vue, web-app-epub-reader/src/App.vue) destructures currentTheme directly without optional chaining, because the real store always initialises a theme.

The correct fix is in the test: use a partial mock that returns a real-shaped store object, as epub-reader does:

useThemeStore: vi.fn(() => ({ currentTheme: ref({ isDark: false }) }))

That removes the need for defensive optional-chaining in production code, and the watcher at line 132 can then track a real reactive dependency.

[LukasHirt]

[Cleanup] menuTitle() duplicates the label of the same extension entry — both return $gettext('HTML file'). If the label is ever renamed, a developer who updates label but misses menuTitle will silently show the old string in the 'New >' create menu while all other surfaces show the new one.

The text-editor avoids this by deriving menuTitle from extensionItem.label directly. Consider the same pattern here, or at minimum extract a shared constant.

[LukasHirt]

[Cleanup] fileSizeLimit (2 000 000 bytes, here) and PREVIEW_SIZE_LIMIT (500 000 bytes, in helpers/preview.ts) are two independent hardcoded thresholds that govern the same file but have no enforced relationship. Currently the wrapper warns at 2 MB while the preview pauses at 500 KB, which is the intended order — but there is nothing to prevent a future edit from reversing them (e.g. raising PREVIEW_SIZE_LIMIT above 2 MB), and no comment explaining the dependency.

Consider adding a runtime assertion PREVIEW_SIZE_LIMIT < fileSizeLimit, or exporting PREVIEW_SIZE_LIMIT from helpers/preview.ts and referencing it here so the relationship is explicit.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[LukasHirt]

Run pnpm format to fix the prettier error please.