Preview

The left column of the editor is a real preview, not a decoration. It renders from the same resolver your storefront uses, at the offsets you configured, on a page-sized surface, so an 88-pixel bottom offset looks like 88 pixels instead of being reported as a number beside a picture that ignores it.

Because both the preview and the public site config read the same resolver, the preview structurally cannot show a colour, size, corner radius or shadow your shoppers would not get. It approximates one thing only: the font. In production a chat bubble's text uses your storefront's own font, which the dashboard can't know, and the preview says so rather than implying it is exact.

The controls change what you look at, never the widgetCopy Anchor Link

Switching to mobile or changing the preview language does not make your draft unsaved.

• Desktop / Mobile: the mobile frame applies your narrow-screen offsets when you have set them, at the same breakpoint the tag uses.
• Template / Real site: Template is a wireframe storefront, drawn as the page type you're simulating (see below). Real site loads your own storefront behind the widget. See below.
• Page type: simulates which page the shopper is on, including Page type not declared, the position of a storefront that never calls customData. It decides two things: whether your targeting would show the widget there (if it's excluded, the scene says so and names the page types it does target, instead of drawing a widget that would not be there, using the same rule the tag applies) and, on the Template surface, which wireframe is drawn (see below). The control stays usable even with Show on all pages on, since it still changes the wireframe.
• Preview language: which language's text to render, from the languages enabled on your site, each named in its own language. This is deliberately not your dashboard's interface language, which bears no relation to your shoppers.

The page scrolls, so you can check what your widget lands onCopy Anchor Link

The template wireframe is drawn as the page type you're simulating: a home page with a hero and product rows, a category page with filters and a grid, a product page with a gallery, price and add-to-cart, or the plain generic page when no type is declared. Each one is taller than the frame and scrolls inside it, because a page that exactly fits the frame can't show the one thing that matters most: whether your chat bubble or question bar ends up sitting on top of something on the real page, like a sticky add-to-cart bar or your footer.

Scroll the page and a floating widget stays exactly where it's docked. That's the point, since that's how it behaves on your real storefront too. A Button or Starters widget scrolls with the page instead, inside a dashed, clearly-marked box: it still makes no claim about where on your page it lands (see An inline widget needs page types), only about how it behaves once it's there.

When the draft has Show starter questions on, the scene also draws the starter-question chips above the widget: the actual three the storefront would serve for the simulated page type and the previewed language, resolved by the same code the public site config uses. Change either control and the chips change with it; on Page type not declared there are none, exactly as on a storefront that never calls customData.

Every one of these is available on a view-only role. Only the preview link needs edit access, because it mints a credential.

Your site's other widgets, and overlapsCopy Anchor Link

The scene draws your site's other live widgets as dashed, non-interactive outlines at their real geometry, so you are adjusting offsets against what your shopper's page actually contains rather than against an empty page.

They are read from what is published, never from their drafts. Another widget's unpublished draft is not on the shopper's page, and drawing it would invent a collision that doesn't exist. A widget that has never been published isn't drawn at all.

When the widget you are editing would land on top of one, the footer warns and names the other widget. It updates live as you change offsets, and it never blocks a save: two widgets deliberately stacked is your call. The footer's right side states the resolved geometry: size, corner radius, and both offsets.

Your own storefront behind itCopy Anchor Link

Switch the scene to Real site and your storefront loads behind the widget. The framed URL is editable and defaults to your site's recorded URL, so you can preview the page type you are actually targeting rather than only the home page. With no URL recorded for the site, the control is unavailable with an explanation and the wireframe still works.

The framed URL carries the tag's own disable parameter, so if you already have the tag installed you don't see your published widget next to the previewed one.

Whether your site allows being framed is checked server-side, from its response headers, not by loading it and waiting for a timeout. When it refuses, the scene falls back to the template, the control is disabled, and it names the header responsible (X-Frame-Options, or the Content-Security-Policy frame-ancestors rule) with a retry offered.

The preview linkCopy Anchor Link

For the cases a dashboard preview cannot settle (does the bubble sit on top of your cookie banner?), Preview link in the action bar creates a short-lived link that shows this widget's draft on your real storefront, with the real tag.

• Only someone with the link sees the draft. Your shoppers keep getting the published version, and every other widget on the page renders from its published version too, so the page is otherwise exactly what a shopper sees.
• It is scoped to one widget. It exposes no other widget's draft, no dashboard access, and no way to write anything.
• It expires after an hour, enforced on the server. Revoke kills it immediately, from the next request.
• There is one link per widget at a time: asking for a new one replaces the old.
• A widget with no draft can't produce one.
• While a link is outstanding, the editor says so, so you don't generate one and forget it exists.

A link that is expired, revoked, malformed or aimed at the wrong widget is treated as no link at all: the published configuration is served, exactly as for any shopper, with no error shown to whoever opened it.