Interactive Rebase Webview remains blank due to unawaited `includeBootstrap` in `WebviewReadyRequest`

[Ichunjo]

Description

The description below has been written by an AI agent as I don't fully understand what's the root issue myself:

In GitLens 19.x, opening the Interactive Rebase Editor frequently results in a blank Webview (or fallback to text editor) when other active extensions / Webviews are present in the shared Extension Host.

1. In WebviewController.onMessageReceivedCore (gitlens.js):

   case S.Ix.is(e): {
       this.respond(S.Ix, e, {
           // BUG: includeBootstrap(!1) returns a Promise, but is not awaited before serialization
           state: e.params.bootstrap ? this.provider.includeBootstrap?.(!1) : void 0,
       })
   }

   Because includeBootstrap(!1) is asynchronous (parseState()), JSON.stringify({ state: Promise }) serializes into {"state": {}}. The Webview frontend receives an empty state object with no entries, causing GlRebaseEditor.render() to return empty/blank.

2. In webview-rebase.js, includeBootstrap(true) withholds the rebase state from the initial HTML generation, forcing full reliance on the broken deferred IPC handshake above.

Suggested Fix

1. Await includeBootstrap:

   state: e.params.bootstrap ? await this.provider.includeBootstrap?.(!1) : void 0

2. In RebaseWebviewProvider.includeBootstrap, return this.parseState() so initial HTML is populated immediately.

GitLens Version

19.0.1

VS Code Version

Version: 1.135.0 (user setup)
Commit: 08d4889f9ec4a1685d257b9b95de036c8e1ce1e5
Date: 2026-08-25T14:26:52Z
Electron: 42.8.1
ElectronBuildId: 14906494
Chromium: 148.0.7778.280
Node.js: 24.18.1
V8: 14.8.178.38-electron.0
@github/copilot: 1.0.81-0
@github/copilot-sdk: 1.0.11
OS: Windows_NT x64 10.0.26200

Git Version

git version 2.55.0.windows.3

Logs, Screenshots, Screen Captures, etc

No response

[eamodio]

This should be resolved in the latest pre-release and coming to stable tomorrow.

[nikolay-1986]

Verification: Passed

Verified on pre-release builds v2026.8.200512 (2026-08-19) and v2026.8.260248 (2026-08-26), Windows, driving the interactive rebase editor live against a deterministic 5-commit fixture (rebase -i HEAD~4).

The editor renders reliably — no blank state:

• all five entries render with their correct SHAs;
• stable across 11+ reopen cycles (3 on the newer build, 8 on the older), including under load with the Commit Graph, Home, and Welcome views open at the same time;
• the reported race did not reproduce on either build.

One correction on the described root cause, noted so it isn't lost: the naive-serialization path in the write-up doesn't appear to be the culprit. Webview IPC already serializes Promises through tagged types (IpcPromise / deserializeIpcData), so a Promise in the bootstrap payload isn't stringified to {} — it becomes a placeholder that settles later. The blank state looks tied to the broader webview RPC lifecycle, hardened by the Supertalk RPC migration rather than by awaiting includeBootstrap.

Not covered

• A true before→after flip: both builds available to me already contain the promise-aware serialization, so this confirms the fixed behavior rather than reproducing the failure and watching it resolve.
• A specific VS Code build number wasn't pinned; the run used the extension's live inspector harness.

[Ichunjo]

Quick update: after digging deeper, this turned out to be an issue in Google AntiGravity.

What actually happened:

To support BigInt serialization, AntiGravity monkey-patches Object.getPrototypeOf(webview).postMessage globally in the Extension Host:

proto.postMessage = function (message, ...args) {
    message = JSON.parse(JSON.stringify(message, ...)); // destroys typed arrays!
    return originalPostMessage.call(this, message, ...args);
};

Because all extensions share the same Extension Host:

1. GitLens sends host-to-webview RPC messages as binary Uint8Array (and deflated bytes).
2. The monkey patch intercepts them and runs JSON.stringify(), turning the Uint8Array into a plain object map: { "0": 123, "1": 34, ... }.
3. The GitLens webview (shared.js) checks t instanceof Uint8Array. Because that check fails, the messages are dropped, the Supertalk RPC handshake never finishes, and the rebase editor stays permanently blank.

Resolution

Fixing AntiGravity locally so it only patches its own webview instance completely resolved the issue for me.

As a defense-in-depth safeguard against other extensions doing this in the shared host, GitLens could consider adding a fallback in shared.js that rehydrates { "0": ... } objects back into a Uint8Array before decoding/decompressing.