Frontend iframe renderer framework: 3D models, OpenAPI (#37233)

Introduces a frontend external-render framework that runs renderer
plugins inside an `iframe` (loaded via `srcdoc` to keep the CSP
`sandbox` directive working without origin-related console noise), and
migrates the 3D viewer and OpenAPI/Swagger renderers onto it. PDF and
asciicast paths are refactored to share the same `data-render-name`
mechanism.

Adds e2e coverage for 3D, PDF, asciicast and OpenAPI render paths, plus
a regression for the `RefTypeNameSubURL` double-escape on non-ASCII
branch names.

Signed-off-by: silverwind <me@silverwind.io>
Co-authored-by: Claude (Opus 4.6) <noreply@anthropic.com>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
This commit is contained in:
silverwind
2026-04-18 00:30:17 +02:00
committed by GitHub
parent 0161f3019b
commit d5831b9385
32 changed files with 540 additions and 293 deletions

View File

@@ -1,10 +1,21 @@
export type FileRenderPlugin = {
// unique plugin name
// there are 2 kinds of plugins:
// * "inplace" plugins: render file content in-place, e.g. PDF viewer
// * "frontend" plugins: render file content in a separate iframe by a huge frontend library (need to protect from XSS risks)
// TODO: render plugin enhancements, not needed at the moment, leave the problems to the future when the problems actually come:
// 1. provide the prefetched file head bytes to let the plugin decide whether to render or not
// 2. multiple plugins can render the same file, so we should not assume only one plugin will render it
export type InplaceRenderPlugin = {
name: string;
// test if plugin can handle a specified file
canHandle: (filename: string, mimeType: string) => boolean;
// render file content
render: (container: HTMLElement, fileUrl: string, options?: any) => Promise<void>;
};
export type FrontendRenderOptions = {
container: HTMLElement;
treePath: string;
contentString(): string;
contentBytes(): Uint8Array<ArrayBuffer>;
};
export type FrontendRenderFunc = (opts: FrontendRenderOptions) => Promise<boolean>;