`%%html` Breaks Positron Notebooks With Inline `<script>`

Introduction

This document details a critical issue encountered in the new Positron notebooks: the use of %%html cells containing inline <script> tags can completely break the notebook renderer. This problem arises specifically when these scripts perform DOM (Document Object Model) manipulation, such as accessing elements via document.getElementById() or modifying the innerHTML property. The result is a severe disruption of the editing session, rendering the notebook unusable and requiring a restart. This issue does not occur in older notebook versions, VS Code notebooks, or JupyterLab, indicating a specific problem within the new Positron environment.

The core of the problem lies in how the new Positron notebook handles sandboxed webviews. When a %%html cell with inline <script> is executed, the script attempts to interact with the DOM. However, the sandboxed environment seems to either lack the necessary permissions or encounters an unhandled exception during this interaction. This leads to a crash of the renderer process, leaving the notebook in a permanently broken state. The severity of this issue is compounded by the fact that the notebook does not recover even after reopening the file, causing significant data loss and frustration for users.

This article aims to provide a comprehensive understanding of the issue, including the steps to reproduce it, the expected behavior, and the error messages observed in the developer tools. By documenting this problem, we hope to facilitate a swift resolution and prevent further disruptions for Positron notebook users. The information provided here is crucial for developers to identify the root cause of the issue and implement a robust solution that ensures the stability and reliability of the notebook environment.

Recording

https://github.com/user-attachments/assets/0988552e-3101-4d65-b1cb-2e3863787244

System details

Positron Version: 2025.12.0 build 35
Code - OSS Version: 1.105.0
Commit: 5418e79f67133ab96a97fc1b3b80e9d3314032e7
Date: 2025-11-06T07:19:04.909Z
Electron: 37.6.0
Chromium: 138.0.7204.251
Node.js: 22.19.0
V8: 13.8.258.32-electron.0
OS: Darwin arm64 25.0.0

Session details:

Python 3.13

Describe the issue

The core issue arises when running %%html cells containing <script> tags that manipulate the DOM (Document Object Model). For instance, scripts that use document.getElementById() to access elements or modify innerHTML are problematic. This behavior causes the new notebook renderer to fail catastrophically. After the script is executed, the notebook's output area ceases to render subsequent cells. All following cells, including those not containing HTML, disappear from view. This loss is irreversible without restarting the environment.

It's important to note that these same code examples function without issues in older versions of Positron notebooks, as well as in VS Code notebooks and JupyterLab. This discrepancy strongly suggests that the problem is specific to the new Positron notebook renderer. The underlying cause is likely related to how the renderer handles sandboxed webviews and the permissions granted to inline scripts within these environments. When the script attempts to interact with the DOM, it may encounter security restrictions or trigger an unhandled exception, leading to the renderer's failure. The fact that the notebook does not recover even after reopening the file indicates a persistent state of corruption, possibly due to the renderer's inability to properly initialize or clear its state after the crash. Addressing this issue is critical to ensure the reliability and usability of the new Positron notebooks.

The impact of this issue is significant, as it can lead to the loss of valuable work and disrupt the user's workflow. Imagine spending hours crafting a complex notebook, only to have it rendered unusable by a seemingly innocuous HTML cell. This can be particularly frustrating for users who rely on HTML and JavaScript for interactive visualizations or custom UI elements within their notebooks. Therefore, resolving this problem is not just a matter of fixing a bug, but also of restoring user confidence in the stability and robustness of the Positron notebook environment.

Expected or desired behavior

As a notebook user, there's an expectation that HTML/JS cells should behave in a predictable and safe manner. Ideally, these cells should either:

• Execute safely within their designated sandbox environment, preventing any interference with the rest of the notebook.
• If execution fails, the system should handle the failure gracefully, providing informative error messages without causing the entire notebook renderer to freeze or become corrupted.

The current behavior is unacceptable because it disrupts the entire editing session. The fact that the notebook renderer crashes suggests that an unhandled exception within the sandboxed webview is causing the renderer process to terminate unexpectedly. This not only leads to data loss but also undermines the user's confidence in the stability of the platform.

To elaborate, when a user inserts an HTML/JS cell, they expect that the code will either execute successfully, producing the intended output, or, in the case of an error, provide a clear indication of what went wrong. A well-designed system would include error handling mechanisms that catch exceptions and prevent them from propagating to the main renderer process. This would allow the notebook to continue functioning, even if a particular cell fails to execute. Furthermore, the error message should provide enough information for the user to understand the cause of the problem and take corrective action. For example, if the script attempts to access a DOM element that does not exist, the error message should clearly indicate which element is missing. In contrast, the current behavior provides no such feedback, leaving the user in the dark about what caused the crash and how to prevent it in the future.

Ultimately, the goal is to create a notebook environment that is both powerful and reliable. Users should be able to freely experiment with HTML and JavaScript without fear of crashing the entire system. This requires a robust sandboxing mechanism that isolates the execution of each cell and prevents it from interfering with the rest of the notebook. It also requires comprehensive error handling that catches exceptions and provides informative feedback to the user. By addressing these issues, the Positron notebook can become a truly indispensable tool for data scientists and other researchers.

Steps to reproduce

To reproduce the issue, follow these steps in a new notebook:

Run the following code in a new notebook cell:

%%html
<div id="output"></div>

<script>
(function() {
 const output = document.getElementById('output');
 output.innerHTML = "<p style='font-size:20px;color:deepskyblue;'>Hello from JavaScript!</p>";
})();
</script>

Observed: No output is displayed, and subsequent notebook cells fail to render.

Expected: The HTML content should be displayed below the cell, or a controlled error should be logged without breaking the notebook.

Example 2 — visualization that also triggers crash

%%html
<div id="output" style="margin-top: 20px;"></div>

<script>
(function() {
 const output = document.getElementById('output');
 const colors = ['#FF6B6B','#4ECDC4','#45B7D1','#FFA07A','#98D8C8'];
 const data = Array.from({length: 5}, () => Math.floor(Math.random() * 100));

 let html = '<div style="display:flex;align-items:flex-end;gap:10px;height:200px;">';
 data.forEach((value, i) => {
 html += `<div style="width:50px;height:${value*2}px;background-color:${colors[i]};
 display:flex;align-items:center;justify-content:center;
 color:white;font-weight:bold;">${value}</div>`;
 });
 html += '</div>';
 output.innerHTML = html;
})();
</script>

Observed: The notebook renderer becomes unresponsive and stops updating.

These steps clearly demonstrate the problem: when JavaScript code within a %%html cell attempts to manipulate the DOM, the Positron notebook renderer crashes, leading to a loss of functionality and a broken notebook state. This issue needs to be addressed to ensure the reliability of the Positron notebook environment.

The root cause of this issue is likely related to the way the Positron notebook handles sandboxed webviews and the security restrictions imposed on inline scripts. When the script attempts to access the DOM, it may encounter security violations or trigger unhandled exceptions, leading to the renderer's failure. To resolve this problem, developers need to carefully examine the sandboxing mechanism and ensure that inline scripts have the necessary permissions to interact with the DOM without compromising the security or stability of the notebook environment.

Notes

• The issue might stem from an unhandled exception or DOM access violation within the sandboxed renderer iframe.
• The error leaves the notebook in a permanently broken state, which does NOT recover even after the file is reopened.

Errors in Developer Tools

This document requires 'TrustedHTML' assignment. Failed to set the 'innerHTML' property on 'Element': This document requires 'TrustedHTML' assignment.

The error message "This document requires 'TrustedHTML' assignment" provides a crucial clue about the underlying cause of the issue. It suggests that the innerHTML property is being used in a context where Trusted Types are enforced. Trusted Types are a web security feature designed to prevent Cross-Site Scripting (XSS) vulnerabilities by ensuring that only trusted data is assigned to potentially dangerous DOM properties like innerHTML. In this case, the script is attempting to set the innerHTML of an element with a string that is not explicitly marked as trusted, leading to the error and the subsequent crash of the renderer.

To resolve this issue, developers need to ensure that all data assigned to innerHTML and similar properties is properly sanitized and marked as trusted. This can be achieved by using a Trusted Types policy to create TrustedHTML objects from the data before assigning it to the DOM. Alternatively, if Trusted Types are not required, the policy can be disabled for the specific context where the script is running. However, disabling Trusted Types should be done with caution, as it can potentially introduce security vulnerabilities. In either case, a thorough understanding of Trusted Types and their implications is essential to ensure the security and stability of the Positron notebook environment.

Learn more about Trusted Types on the official web.dev documentation