Add a navigate action to integration block webframes#4362
Merged
gregberge merged 9 commits intoJul 10, 2026
Merged
Conversation
Expose the current page (id, path, title) to integration block webframes via the client-only webframe state, reusing the same postMessage channel as adaptive visitor claims. The page is sourced from the block's server-side content context rather than the integration render request, so the integration render cache is unaffected. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Only expose the current page to a webframe when the integration's render output declares it can access page context (canAccessPageContext), mirroring canAccessVisitorClaims. The @gitbook/api type does not yet include the flag, so the read is temporarily annotated with @ts-expect-error. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
🦋 Changeset detectedLatest commit: a5f3b7e The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Contributor
|
The latest updates on your projects. Learn more about Argos notifications ↗︎
|
Per review (avoid another customer-specific integration scope): expose the current page to webframes unconditionally, since path/id/title are non-sensitive (no shareKey or token). Also add a @webframe.navigate action so a webframe can navigate the reader to another page within the space, resolved client-side against the space base path via the router. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
gregberge
commented
Jul 3, 2026
Address review: resolve the @webframe.navigate action against the site base path (toPathInSite) rather than the current space, so a webframe can navigate to a page in any section or space of the site. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
taranvohra
reviewed
Jul 9, 2026
Give `getPageContext` a concrete `{ page: { id, path, title } }` shape
instead of `Record<string, unknown>`, and split webframe navigation into
`navigateToPath` (sync, resolved against the site base path) and
`navigateToPageId` (async, resolved against the site's page tree via a
server action) so a webframe can address a destination either way.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Route webframe `navigateToPath`/`navigateToPageId` through `onNavigationClick` before `router.push`, so a reader gets the same top loading bar feedback as a regular in-app link click (previously these bypassed the navigation status and showed nothing). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
taranvohra
reviewed
Jul 10, 2026
Address review: stop duplicating the linker's path-join logic and drop the
async server action for page-id resolution.
- Rebuild the (tested) `GitBookLinker` on the client from serializable data
passed by `IntegrationBlock`, and resolve `navigateToPath` via
`linker.toPathInSite` (removes the hand-rolled `joinPath`).
- Ship a compact `{ pageId: path }` map (built server-side from the current
revision) so `navigateToPageId` resolves synchronously against real pages,
removing `resolveWebframePagePath` and its site-context refetch.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Collapse `navigateToPath`/`navigateToPageId` into one `navigate(target)`
accepting `{ path, anchor? } | { pageId, anchor? }`, branching on the
destination kind internally.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
taranvohra
approved these changes
Jul 10, 2026
Reduce the webframe integration to navigation by path only:
- Remove the current-page context (`state.page` / `getPageContext` /
`getWebframePageContext`) and its types.
- Remove `pageId` from `@webframe.navigate` and the supporting page-path
map (`getWebframePagePaths`).
`navigate({ path, anchor? })` resolves client-side via the rebuilt linker;
pre-existing visitor claims are unchanged.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Lets an integration block webframe navigate the reader to another page in the site, over the client-only webframe postMessage channel (the same channel as adaptive visitor claims):
@webframe.navigate— a webframe posts this action to navigate the reader to another page in the site, addressed bypath(with an optionalanchor). The path is resolved against the site base path, so a webframe can link to a page in any section or space of the site — and nowhere outside it.Navigation is resolved entirely client-side (never through the integration render request), so the integration render cache is unchanged, and it drives the standard navigation progress bar.
Usage (from inside a webframe)
The webframe communicates with GitBook over
postMessage, exactly like the existing resize/ready protocol. Post a@webframe.navigateaction with a site-root-relativepath:Why
RND-11604 — integrations (e.g. harness) need to navigate the reader to other pages within the site from a webframe. Docs: GitbookIO/integrations#1230.
How it's wired
navigate({ path, anchor? });ElementWebframemaps the@webframe.navigatemessage to it.GitBookLinker(toPathInSite), rebuilt from serializable data passed byIntegrationBlock— no duplicated join logic, no server round-trip.Notes
@gitbook/apior backend change — the gitbook-x companion PR was closed.state.pagecurrent-page context andpageId-based navigation were removed; this PR now only adds@webframe.navigateby path. Pre-existing visitor claims are unchanged.Test plan
bun run typecheck— 27/27bun testonadaptive.test.ts— 3/3biome checkon changed files — clean🤖 Generated with Claude Code