Markdown editor

[abose]

This PR introduces a full-featured markdown live preview editor (src-mdviewer/) that replaces the basic markdown rendering with a rich WYSIWYG editing experience in the live preview panel.

Screenshots

edit mode

Reader mode

Major Features

• Rich markdown editor — contenteditable-based WYSIWYG editing with toolbar, slash menu (/ commands), and format bar
• Bidirectional sync — real-time sync between CodeMirror source and the visual editor, including cursor/scroll position sync
• Document cache — persistent iframe with DOM caching for instant file switching (working set + LRU)
• Image paste-to-upload — paste/upload images from clipboard or file picker, auto-compress, cloud upload via assets.phcode.dev
• In-document search — Ctrl+F search with mark.js highlighting, per-document index preservation
• Print support — print button with light theme forcing and proper page layout
• Table editing — row/column handles, context menus, add/delete row/column/table, cell navigation
• List editing — Enter splits bullets, Tab/Shift+Tab indent/outdent, UL/OL type switching
• Heading editing — Enter splits at cursor, Backspace at start converts to paragraph, context-aware behavior
• Code block editing — ArrowDown/Shift+Enter exits to paragraph below
• Entitlement gating — edit mode gated behind pro/trial entitlement with upsell dialog

Architecture

• src-mdviewer/ — Vite-built iframe app with its own i18n, themes, and component system
• Communicates with Phoenix via postMessage bridge (bridge.js ↔ MarkdownSync.js)
• Separate iframe ID (panel-md-preview-frame) to avoid duplicate DOM IDs with HTML live preview
• Sandboxed without allow-same-origin for security (scripts in rendered markdown can't access Phoenix context)
• morphdom for incremental DOM updates with image node preservation (no reload/flicker)
• ImageUploadManager service provider pattern — core registry, pro extension implements upload

Security

• mdviewer iframe sandbox: allow-scripts allow-popups allow-popups-to-escape-sandbox allow-modals (no allow-same-origin)
• EventManager silently ignores null origin messages from sandboxed iframes
• No sandbox in test windows for integration test compatibility

Testing

• Updated LiveDevelopmentCustomServer-test.js and LiveDevelopmentMultiBrowser-test.js for new iframe architecture
• Added test for play button/mode dropdown hidden on markdown files
• 62/62 MultiBrowser LP tests passing, 35/35 Custom Server LP tests passing
• Comprehensive test plan in src-mdviewer/to-create-tests.md

Other Changes

• Assets proxy route in serve-proxy.js for browser dev builds
• H4/H5 support in block type selector and slash menu
• End/Home key fix near images in contenteditable
• Edit mode preserved across project switches

Test plan

• Open markdown file — rich preview with toolbar appears
• Edit in CM — preview updates without image reload
• Edit in preview — syncs back to CM
• Paste image — uploads to cloud, embed URL inserted
• Ctrl+F — in-document search works
• Print button — prints with light theme, proper margins
• Table editing — add/delete rows/columns, navigation
• File switching — instant with cached DOM
• Project switch — cache clears, edit mode preserved
• All LP integration tests pass (62 + 35 = 97 tests)

[github-advanced-security]

SonarCloud found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.

In general, to fix this kind of issue you must not assign untrusted strings directly to dangerous DOM properties (src, href, innerHTML, etc.) without validation. Either (a) validate and constrain the value to a safe subset (e.g., only allow HTTPS URLs from trusted hosts) or (b) encode/escape it and insert it only into safe contexts.

The best minimal fix here is to validate embedURL before assigning it to placeholder.src. Since we cannot modify other files, we add a small helper in bridge.js that checks the URL using the built-in URL constructor and only allows safe protocols such as http: and https: (and optionally same-origin relative URLs). _handleImageUploadResult will call this helper; if validation fails, we treat it like an error (remove the placeholder instead of embedding a potentially dangerous URL). This preserves existing behavior for legitimate URLs while blocking attacker-controlled schemes like javascript: or data:.

Concretely:

• In src-mdviewer/src/bridge.js, above _handleImageUploadResult, define a function sanitizeEmbedUrl(rawUrl) that:
  • Returns null if rawUrl is falsy.
  • Attempts to construct a URL object, using window.location.href as base for relative URLs.
  • Only returns the URL’s href if its protocol is in an allowed list (http: and https:). Otherwise returns null.
• In _handleImageUploadResult, replace use of embedURL with the sanitized result:
  • Compute const safeEmbedURL = sanitizeEmbedUrl(embedURL);
  • Change the condition from if (embedURL) to if (safeEmbedURL) and assign placeholder.src = safeEmbedURL;.
• No new external dependencies or imports are required; we rely on the built-in URL class.

To fix the problem, keep sanitizing the pasted HTML but additionally validate and normalize any URL-bearing attributes (href, src) before allowing them, and remove or neutralize any values with dangerous schemes (like javascript:, vbscript:, data: for non-images, etc.). This keeps existing functionality (pasting formatted content with links and images) while blocking XSS vectors.

Concretely, in src-mdviewer/src/components/editor.js, inside sanitizePastedHTML, we should:

1. Add a small helper to determine whether a URL is safe:
   • Allow only certain schemes: empty/relative URLs, http:, https:, mailto: (and optionally others you deem safe).
   • Reject anything starting with javascript:, vbscript:, or other non-HTTP(S) schemes.
2. When iterating over attributes:
   • Still preserve alt as harmless.
   • For href and src, only keep them if they pass the new URL validation; otherwise remove those attributes.
   • We can still limit attributes to the allowlist as currently done.
3. Optionally, we can further constrain IMG src to http/https and safe data:image/... URLs, but at minimum we must remove javascript: and similar.

Implementation details:

• Add a small function isSafeUrl(url) above or inside sanitizePastedHTML. Since we must only edit the provided snippet, define it just above sanitizePastedHTML in editor.js. Use standard string checks and URL constructor where possible, but fall back gracefully on exceptions.
• Modify the block that currently keeps href, src, alt unconditionally:

if (attr.name === "href" || attr.name === "src" || attr.name === "alt") continue;

to:

• Always keep alt.
• For href / src, call isSafeUrl(attr.value) and only keep them if that returns true; otherwise remove the attribute.

No new external dependencies are necessary; we can use built-in URL and basic string operations.

In general, to fix “DOM text reinterpreted as HTML” issues, you should avoid feeding untrusted strings directly into innerHTML or similar DOM sinks. Either (1) sanitize the HTML using a robust library before assigning it, or (2) use DOM APIs that treat the data as text (like textContent) or as data within a constrained context (e.g., SVG parsing) rather than as free-form HTML.

For this specific file, the vulnerable line is:

const temp = document.createElement("div");
temp.innerHTML = svg;
const svgEl = temp.querySelector("svg");

The rest of the code then only uses svgEl. A minimal, behavior-preserving hardening is to sanitize svg before putting it into innerHTML. The most standard way in front‑end JS is to use DOMPurify, which is well-known and specifically designed to sanitize HTML/SVG. Since we are allowed to import well-known external libraries, we can:

1. Add import DOMPurify from "dompurify"; at the top of src-mdviewer/src/components/mermaid-editor.js.
2. Replace temp.innerHTML = svg; with temp.innerHTML = DOMPurify.sanitize(svg, {USE_PROFILES: {svg: true}});. This keeps only safe SVG constructs and strips scripts/unsafe URLs/etc., addressing all variants where the tainted source/textarea.value ultimately flows into this innerHTML.
3. No other functionality changes are needed; the code still parses the sanitized SVG into a temporary container, selects the <svg> element, applies accessibility attributes, and injects it into the preview.

This modification is entirely local to the shown region and doesn’t change semantics except for dropping potentially unsafe content that Mermaid might emit under attacker control.

General approach: Avoid using innerHTML to convert an SVG string into DOM nodes. Instead, parse the SVG string into a Document using DOMParser with the "image/svg+xml" MIME type, and extract the <svg> element from that parsed document. This way, the browser treats the string as SVG markup only, not as generic HTML that could include script elements or event handlers outside of SVG context. This also resolves CodeQL’s concern about DOM text being reinterpreted as HTML.

Concrete fix:

1. In reRenderDiagram (around lines 296–299), replace:

   const temp = document.createElement("div");
   temp.innerHTML = svg;
   const svgEl = temp.querySelector("svg");

   with code that uses DOMParser:

   const parser = new DOMParser();
   const parsed = parser.parseFromString(svg, "image/svg+xml");
   const svgEl = parsed.documentElement && parsed.documentElement.tagName.toLowerCase() === "svg"
       ? parsed.documentElement
       : parsed.querySelector("svg");

   This preserves functionality (we still obtain an <svg> element) but avoids innerHTML.

2. In closeEditor (lines 268–273), similar pattern: instead of using temp.innerHTML = lastValidSvg, parse the saved SVG string with DOMParser and append the resulting <svg> node:

   const parser = new DOMParser();
   const parsed = parser.parseFromString(lastValidSvg, "image/svg+xml");
   const svgEl = parsed.documentElement && parsed.documentElement.tagName.toLowerCase() === "svg"
       ? parsed.documentElement
       : parsed.querySelector("svg");

   Then append this svgEl to diagram.

No additional imports are needed; DOMParser is a standard Web API. We keep all other behavior intact: the editor still restores lastValidSvg, still applies accessibility settings, and still re-renders diagrams.

General fix: avoid using innerHTML with data derived from untrusted content. Instead, parse and insert the SVG in a way that does not execute arbitrary HTML/JS. The best option in this context is to use DOMParser with the "image/svg+xml" MIME type and then extract the <svg> element from the resulting document. This avoids going through HTML parsing and prevents things like <script> tags or other non-SVG HTML from being interpreted in the HTML context.

Concrete change:

• In both places where svg is currently handled:

  const temp = document.createElement("div");
  temp.innerHTML = svg;
  const svgEl = temp.querySelector("svg");

  replace this with code using DOMParser:

  const parser = new DOMParser();
  const doc = parser.parseFromString(svg, "image/svg+xml");
  const svgEl = doc.querySelector("svg");

• This stays within the same file src-mdviewer/src/core/mermaid-render.js and does not alter any external behavior other than how the SVG string is turned into a DOM node. The rest of the logic (accessibility, animations, error handling) remains unchanged.

• DOMParser is a standard Web API; no imports are needed. We also do not need to hold a shared parser instance; creating it where needed keeps changes minimal and clear.

This single change removes the use of .innerHTML for tainted content and therefore addresses all variants of the alert, since both rendering paths use the same pattern.

In general, the fix is to avoid assigning untrusted or tainted strings directly to innerHTML. Instead, create DOM nodes in a way that does not reinterpret the string as HTML, or use a parsing mechanism that is restricted to SVG/XML and does not execute scripts or event handlers.

In this specific code, we only need the <svg> element from the svg string returned by Mermaid. We can obtain that <svg> element without using innerHTML by using DOMParser with the "image/svg+xml" MIME type; this parses the string as SVG/XML rather than HTML and gives us a document whose root is an <svg> element. We can then import or clone that node into the current document and append it to wrapper. This preserves existing functionality (we still render the exact same SVG), while removing the innerHTML use that CodeQL flags.

Concretely, in src-mdviewer/src/core/mermaid-render.js, within reRenderMermaidBlocks:

• Replace the creation of temp and temp.innerHTML = svg; / temp.querySelector("svg") with a DOMParser call:
  const parser = new DOMParser(); const svgDoc = parser.parseFromString(svg, "image/svg+xml"); const svgEl = svgDoc.documentElement;.
• Optionally, guard that svgEl is indeed an SVGSVGElement (its tagName equals "svg" ignoring case) before using it.
• Keep the rest of the logic (accessibility application, clearing wrapper.innerHTML, appending the SVG) unchanged.

No new external npm dependencies are required; DOMParser is a standard Web API available in browsers.

In general, to fix this issue, we need to ensure that the URL assigned to placeholder.src is not fully attacker-controlled. This can be done by: (1) authenticating the message source (checking event.origin and/or a shared secret in event.data); and/or (2) validating embedURL against a whitelist of allowed schemes or patterns before using it.

The least invasive, functionality-preserving fix here is to validate embedURL before assigning it to placeholder.src. A robust approach is to parse the URL via the built-in URL constructor and enforce a whitelist of safe protocols, e.g., allow only https:, http: (if you must), data: (for embedded images), and perhaps blob:. If parsing fails or the protocol is not allowed, treat it as an error and remove the placeholder instead of setting the src. This preserves the existing behavior for valid URLs while preventing redirection/loading of arbitrary, potentially dangerous schemes (like javascript:).

Concretely, in src-mdviewer/src/bridge.js, inside _handleImageUploadResult, modify the block that currently does:

if (embedURL) {
    placeholder.src = embedURL;
    placeholder.alt = placeholder.alt === "Uploading..." ? "" : placeholder.alt;
    placeholder.removeAttribute("data-upload-id");
} else {
    placeholder.remove();
}

Change it so that:

1. If embedURL is falsy, keep removing the placeholder as before.
2. If embedURL is truthy, attempt to construct a new URL(embedURL, window.location.origin):
   • On error (invalid URL), remove the placeholder and return.
3. Check url.protocol against a small whitelist, e.g. ["https:", "http:", "data:", "blob:"].
   • If not allowed, remove the placeholder and return.
4. Only then set placeholder.src = embedURL and proceed with updating alt and removing data-upload-id.

No new imports are needed because URL is a standard Web API. This keeps the protocol of the image under control while minimally impacting existing flows where embedURL is already a valid, safe URL.

---

[sonarqubecloud]

Quality Gate failed

Failed conditions
D Security Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE