Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Lazy loading (level 3) for a browser host: load later parts through the host

未关闭
  • 哪里不对？
#1,278 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
35/100
Issue 类型
功能
描述清晰度
描述清楚
活跃度
活跃
技术栈
cpp, html, wasm
领域
api, backend, web-dev

调研方向

Read docs/design/lazy-loading.md decision 2, then trace load(chunk) in viewport.js, HtmlService::write(path), and the wasm binding in wasm/src/wasm_html.cpp (to_html_config) and wasm/js/index.d.ts. The report describes the host bridge, per-document path writing, wasm config, and sandbox constraints; completion means browser hosts can load later parts on demand while file and HTTP loading still work.

由索引模型根据 Issue 内容生成。

描述

What is missing

With HtmlConfig::lazy_loading, a page loads each later part of a view as a script beside it: text-chunks/<n>.js, sheet<n>-chunks/<m>.js, pdf-pages/<n>.js, and the search index (*-search/<n>.js). viewport.js adds a <script src> with a relative path (docs/design/lazy-loading.md decision 2). That works from file:// and over the HTTP server.

A browser host cannot use it. The website (opendocument.app, on @opendocument/odr-core through wasm) renders into a sandboxed srcdoc iframe:

  • sandbox="allow-scripts" without allow-same-origin, so the frame has no origin
  • CSP script-src 'self' 'wasm-unsafe-eval' 'unsafe-inline', connect-src 'self'
  • no file server

A relative <script src> has nowhere to load from there. The wasm binding also does not read lazyLoading (wasm/src/wasm_html.cpp, to_html_config; wasm/js/index.d.ts). So in 7.6.x a browser host gets level 1 (lazyLayout) only.

What it would take

  1. A host hook in viewport.js. When the page has a host to ask, load(chunk) asks the host for the part named by data-odr-chunk-src (and data-odr-chunk-text for the index) instead of adding a <script src>. For example: post {type: "loadPart", path} through the host bridge, and accept the answer as the script text, or as the html of the part, passed to odr.chunks.fill and odr.chunks.text. The script tag stays the default, so file:// and HTTP do not change.
  2. A wasm call that writes a path. C++ has HtmlService::write(path) (and exists, mimetype), and it renders a part on demand. The wasm binding does not expose it. Something like doc.write(path) returning the text, kept per open document, so the host can answer the hook.
  3. lazyLoading in the wasm config, with the hook as its precondition. The README and index.d.ts should say so.
  4. The sandbox: the answer must reach the frame without allow-same-origin. postMessage into the frame and eval-free insertion fit the site's CSP, because odr.chunks.fill takes html, not code.

Why

The site caps a sheet at 50,000 cells, because the whole markup goes into srcdoc as one string. Level 3 would let it show far larger files: the page holds only the first part, and the rest comes from the open document on demand. It is the same win as on the server: for Core_v5.1.pdf, 1.4 MB instead of 127 MB.

Reported by the website session after moving the site to 7.6.0.

主要语言
C++
星标
41
派生
10
平均合并
10 小时 30 分钟
30 天内合并 PR
342

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

opendocument-app/OpenDocument.core 的其他 Issue

查看 opendocument-app/OpenDocument.core 的全部 Issue

相似的 Issue

更多 C++ Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。