Fix copy/paste and context menus for Shiny and other content in Viewer pane

[jmcphers]

Intent

This change makes copy, paste, and context menus work correctly inside Positron's Viewer pane when it's showing content from a URL, including from Shiny, Streamlit, etc.

Addresses #2993.

Approach

To understand how this works, it's necessary to understand how VS Code's webviews work under the hood. They use a nested pair of <iframe> elements. The first <iframe> loads a host page, which creates the second (inner) <iframe> . When you set a webview's content, it pushes the HTML from VS Code to the first layer using a window message called content.

graph TD
wv[Webview] -- postMessage(content) --> h[Host iframe - index.html] -- set content --> c[Content iframe - same origin]
c -- events --> h -- postMessage(event) --> wv

Loading

After the content is loaded, the host iframe sets up a bunch of event handlers to trap keyboard/mouse/etc. events in the content frame, which is possible since the pages share a security context (same origin). When events are received, they are dispatched back up to the Webview via postMessage. This is what makes copy, paste, and context menus work.

Tools like Simple Web Browser and Positron's own Viewer allow you to load external URLs. They do this by setting content HTML that itself has an <iframe> tag pointing to the URL. This means that the content is loaded into a frame that is three iframes deep in the stack.

graph TD
wv[Webview] --> h[Host iframe - index.html] --> c[Content iframe - same origin] --> u[URL iframe - different origin]

Loading

This is why the events that power copy/paste/context menus/etc. do not work in Simple Web Browser. All the event handlers are on the content <iframe> one layer up, and we couldn't push them down to the URL iframe if we wanted to -- it's on a different origin.

This change establishes a parallel way of loading content into webviews; instead of loading raw HTML content into the content iframe, we have it load the desired URL directly.

And instead of attaching the event handlers from outside the content, we inject them into the content page itself using an Electron API called executeJavaScript. Here are both scenarios side by side, for comparison; the left is the usual WebView workflow and the right is the new one.

graph TD
wv[Webview] -- postMessage(content) --> h[Host iframe - index.html] -- set content --> c[Content iframe - same origin]
c -- events --> h -- postMessage(event) --> wv
wv -- postMessage(uri) --> h2[Host iframe - index-external.html] -- set URI --> c2[Content iframe - different origin]
evjs[webview-events.js] --> executeJavaScript --> c2
c2 -- postMessage(events) --> h2
h2 -- postMessage(events) --> wv

Loading

By eliminating one layer of frames and injecting event handlers using Electron APIs, we can make events work inside the content iframe even though it's on a different origin.

We can't use this executeJavaScript stunt in web browsers, so all of this new machinery only lights up on Electron -- but that's no big deal since real web browsers have their own copy/paste commands (etc) that already work.

QA Notes

This fix only applies to content loaded in Positron's native Viewer pane as a URL. Content loaded in the Simple Web Browser uses the old codepath and won't get this new behavior. (We could make it work, of course! But outside the scope of this change.)

Conversely, it applies to all content loaded into the Viewer pane as a URL. This includes Shiny, Streamlit, Dash, Flask, Plumber, etc. It's worth testing at least a couple of these.

The Quarto extension does not load content into the Viewer pane as a URL (it loads its own web browser control) and is therefore largely unaffected by this change.

The change uses Electron APIs and should be tested on at least two platforms.

[softwarenerd]

Amazing PR. Amazing writeup.

[softwarenerd]

Tiny idea: You can just call get and avoid has then get.

[jmcphers]

Good idea! Done in bc8da7d