Related

• Closes Eliminate notebook widget timeouts #9886

What

We want to store the Wasm binary as a separate file, and let the Viewer load it via fetch at runtime. This leads to the best outcomes in terms of startup times.

Build changes

The rerun_notebook build has been updated to:

• Copy the Wasm binary from node_modules to /static
• Preserve special inline marker comments (//!<INLINE-MARKER> at the time of writing)

We manually copy the Wasm binary to the output directory, because any of my attempts to do this via esbuild failed. We just need the file there, so we do it manually.

We need to mark the start and end of a block of code that should be replaced with the inlined Wasm binary + the glue that loads it from a base64-encoded string. We use esbuild to bundle the notebook widget, and esbuild does not preserve regular comments. There are also no options to enable this behavior.
The exception is "legal comments" which are normally used for e.g. copyright information. The marker comments just happen to be something that esbuild considers a "legal comment".

The rerun-js/web-viewer build no longer combines the Wasm and JS into a single file - this is instead done at runtime, by the rerun_notebook package, becuase we don't want to publish two copies of the Wasm binary (one as its own file, one inlined into the JS widget) when publishing the package. It has a negligible startup cost, which is paid once at time of import rerun.notebook, and only if RERUN_NOTEBOOK_ASSET is set to inline.

The asset server has been updated to also serve the re_viewer_bg.wasm file. It serves it gzipped, with the right content-type so that it can be stream-compiled.

Check for assets

We now send a HEAD request to check if the assets we need are accessible on the browser side, by injecting a small JS snippet in parallel with the regular Viewer widget loading. This injection is done via a combination of ipywidgets.HTML and a base64-encoded javascript file inserted into a style tag's onload property.

It's done in this convoluted way because ipywidgets.HTML uses innerHTML to set the content of the element it creates. JS is not executed by running innerHTML (see https://developer.mozilla.org/en-US/docs/Web/API/Element/innerHTML#security_considerations)... except if it's in special properties which are treated as event listeners. It's base64-encoded so that the javascript we inject does not need to avoid using quotes or other symbols which may cause the resulting HTML string to not parse properly.

If the widget isn't accessible, we let the user know with a clear error message.

Additionally, the rerun_notebook import has been moved from inside the Viewer constructor to the top-level again. Despite rerun_notebook being an optional package, we've been able to do this without causing any issues for a while, because we no longer import the rerun.notebook package anywhere inside rerun-sdk eagerly. Something like blueprint _ipython_display_ impls import it inside the function body, at which point we expect the user to have the rerun_notebook package installed, because we expect _ipython_display_ to be called from the context of a notebook. If someone tries to call it outside of that context, that's their problem ¯\_(ツ)_/¯.

block_until_ready=False by default

If the widget asset was not accessible for whatever reason, the widget would never finish loading without any error messages, unless you opened the browser devtools console. That was a super frustrating experience, so we instead set a hard limit (10 seconds) for how long the Viewer should take to load, and blocked cell execution until it did. Those 10 second turn out to just not be enough in many environments.

Because we now check if the required assets are accessible in the browser, we no longer need this, as we won't ever timeout in the same way. We already buffer all input data before the widget has loaded, so there is no issue with letting cell execution continue while the widget is loading.