Sync Behavior

Mosaic's reason for existing is that the three panes stay in sync. This page documents exactly what is and isn't kept in sync, and how the sync mechanisms work in practice.

Scroll sync

Scroll any pane and the other two follow. The sync uses two strategies in priority order:

Anchor element. Mosaic finds an identifiable element near the top of the visible viewport in the source pane (preferring elements with id, data-testid, headings, or sectioning landmarks) and scrolls each other pane until that same element is in roughly the same position. This is robust against pages where the layout differs significantly between viewports - the scroll position lines up by content, not by pixel.
Scroll percentage fallback. When no shared identifiable element is in the visible viewport (rare, but happens on pages with no semantic markup), Mosaic falls back to mapping the source pane's scroll percentage onto the other panes. This is less precise but always works.

The sync is broadcast in real time as you scroll - there's no debounce or visible lag. Rapid scrolling, programmatic scroll-into-view, and anchor-link clicks all trigger the same broadcast.

Click sync

Click any link or button in any pane. If the click triggers a navigation - in-page anchor jump, internal link, external link, form submit, or programmatic location.href assignment - the destination URL is broadcast to the other two panes and they navigate to it.

Sync is implemented via Chromium's did-navigate event on each WebContentsView. Whenever any pane fires did-navigate, Mosaic forwards the new URL to the other two panes. This catches:

Standard <a href> link clicks.
Form submissions resulting in a redirect.
Programmatic navigation via window.location, location.assign, or location.replace.
Server-side redirects.
SPA route changes that update the URL via history.pushState or history.replaceState.

Back and forward navigation

The toolbar has Back and Forward buttons. Clicking Back steps every pane backwards in its own history stack simultaneously. Each pane keeps its own independent history, but the buttons drive them together.

The buttons enable themselves once any pane has at least one navigation event in its history. They disable when no pane can go further in that direction. This means navigation buttons broadly track the global state: if any pane has somewhere to go back to, Back is enabled.

Shared session

All three panes use a single Chromium session partition: persist:mosaic-shared. This means cookies, localStorage, sessionStorage, IndexedDB, and Service Worker registrations are shared across panes.

The practical result: log in once and every pane is logged in. This makes Mosaic useful for:

Testing authenticated pages and dashboard layouts at multiple breakpoints.
Verifying paywall and member-gated content rendering.
Walking through a multi-step flow (cart, checkout, onboarding) where the state lives in cookies or storage.

The session persists across app restarts because the partition is prefixed persist:. To start fresh, see Cache & DevTools for the purge cache button - which clears HTTP cache only, not cookies. To clear cookies and storage, you'll currently need to do it via DevTools' Application tab in any pane.

What is not synced

Form input. Typing into a form field in one pane does not echo into the other panes. This is intentional - sync would interfere with comparison testing of how forms render and validate at different widths.
Hover states. Hovering in one pane does not trigger hover in the others. Each pane responds to its own cursor independently.
Per-pane scroll within nested scrollable elements. The scroll sync targets the page's main scroll. Nested scrollable containers (like a modal body, side drawer, or carousel) scroll only in the pane the wheel event happened in.
JavaScript console state. DevTools opened on each pane is independent.

Reload all

The toolbar reload button (or Cmd+R) reloads all three panes simultaneously while preserving the URL.