Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#1,278 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
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分
マージ済み PR（30日）
342

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

opendocument-app/OpenDocument.core のほかの issue

opendocument-app/OpenDocument.core の issue をすべて見る

似ている issue

C++ の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。