Troubleshooting
The Visual Editor handles most real-world pages out of the box. When something doesn't work, the cause is usually one of the scenarios below.
Shadow DOM
Some sites build parts of a page as self-contained custom elements that keep their own private markup, called a shadow root. The Visual Editor cannot edit inside one, whether the site left it open or closed.
Hovering over such an element highlights the custom element that owns it rather than the piece under your cursor. Clicking selects nothing and the panel tells you why.
The panel goes read-only and names the custom element: "That element lives inside a shadow root (my-widget). The visual editor can't reach into shadow DOM, so click an element outside it." The notice clears itself after a few seconds.
Two ways forward: edit the element that wraps it on the host page, which works normally, or ship the change inside the custom element as production code.
Cross-origin iframes
For security, browsers block scripts from one origin from accessing the DOM of another. If your page embeds a payment widget, chatbot, or video player from another domain, the snippet inside that iframe is a different snippet: your edits don't cross the boundary.
The editor detects when the element you clicked lives inside a cross-origin iframe and disables the edit form, instead suggesting you target the host page's wrapper element. Edits to the wrapper (size, positioning, visibility) work fine; edits to the iframe's contents do not.
Snippet not detected
A vs B checks whether the snippet is live on your site before the editor opens. If it isn't, clicking Edit with Visual Editor stops on a Snippet not detected dialog that reads "We haven’t detected the AvsB snippet on your site, so the visual editor may open to a blank page. Install the snippet on the target page first, then try again." Choose Cancel to fix the install first, or Open anyway to continue.
Most common causes and fixes:
- The snippet isn't installed: Check Quick install and verify by opening the browser dev tools console and typing
window.avsb. - Snippet is installed on a different environment: Confirm the URL in your experiment matches the environment where the snippet runs (staging vs production).
- An ad blocker is interfering: Some aggressive blockers match the snippet URL. Pause the blocker on the editing domain.
- Consent mode is denying the snippet: See the consent mode section below.
Lock conflicts
Only one teammate can edit a variation at a time. When somebody else opens the same variation, you'll see the message "Maya is editing this variation" in the panel header. Saving is disabled until they finish or the lock expires.
- The lock TTL is 5 minutes of inactivity. Once it expires, the next person to open the variation receives the lock.
- While you're actively editing, the editor renews your hold every 10 seconds. Close the editor or the tab and the renewals stop, so the lock frees itself once the 5 minutes are up.
- If you save more than 30 times in one minute, the API rate-limits further saves until the next window opens. This guards against runaway scripts; manual editing never hits this limit.
- To force a takeover, click Request edit access. The current editor receives a prompt to release the lock.
CORS
If your site's Content-Security-Policy doesn't allow the A vs B snippet origin, the editor can't inject its overlay. Symptom: the editor opens but nothing on the page is clickable and the browser console logs CSP violations.
Add the directives below (or the equivalent for your CSP). This is the complete policy a page needs to run A vs B, the same one published on every page of these docs that mentions CSP, so you never have to collect it from more than one place:
script-src 'self' https://cdn.avsb.cloud 'unsafe-inline' 'unsafe-eval';style-src 'self' 'unsafe-inline';connect-src 'self' https://cdn.avsb.cloud https://ingest.avsb.cloud https://app.avsb.cloud;img-src 'self' https://assets.avsb.cloud;What each part is for:
https://cdn.avsb.cloudinscript-src: the snippet bundle and its on-demand pieces load from our CDN.'unsafe-inline'inscript-src: the first half of the install tag is a small inline script that hides the page before the first paint; an external file would arrive too late to prevent the flash it exists to prevent. Nonce variant: if your platform can stamp a per-request nonce, addnonce="..."to BOTH halves of the install tag (the inline stub and the loader tag) and usescript-src 'self' 'nonce-...' https://cdn.avsb.cloud 'unsafe-eval'instead; browsers ignore'unsafe-inline'when a nonce is present, so this is the stricter policy.'unsafe-eval'inscript-src: the code you write in the experiment builder (variation JavaScript, project JavaScript, triggers, Custom JavaScript audiences) is compiled in the visitor's browser; without this directive every experiment that carries custom code stops running.style-src 'unsafe-inline': variation CSS is applied as an inline style element. There is no nonce workaround for styles the runtime injects. Ifscript-srcallows the snippet butstyle-srcblocks inline styles, visitors are bucketed and counted while seeing the control's styling; the snippet reports this to your experiment's error log as an apply failure, but the fix is the directive.connect-src: the CDN serves your configuration,ingest.avsb.cloudreceives events and error reports, andapp.avsb.cloudanswers preview links and editor sessions (and the SDK heartbeat and stream ticket where you use them). A browser flag SDK with streaming on also needshttps://stream.avsb.cloud, where its live updates arrive.img-src https://assets.avsb.cloud: images you upload in the editor are served from there.
Once added, reload. The editor should attach cleanly on the next page load. The canonical copy of this policy, kept alongside the full host list, is Data-plane endpoints and credentials.
Replacement images blocked by the site's security policy
Images you upload as replacements are served from assets.avsb.cloud. If the site's Content-Security-Policy has an img-src directive that doesn't allow that host, the browser refuses to load the new image, for you in the editor and for visitors alike. The editor detects the failed load and tells you plainly: "This site's security policy may be blocking images from assets.avsb.cloud. Paste an image URL hosted on this site, or allowlist assets.avsb.cloud in the site's img-src."
Two fixes:
- Paste a same-site image URL. Host the replacement wherever the site already serves images from, and paste that URL into the image source field instead of uploading. Same-site images are never blocked by
img-src 'self'. - Allowlist the host. Ask whoever owns the site's CSP to add
assets.avsb.cloudto theimg-srcdirective.
"Saving is paused to protect them"
If the editor couldn't load a variation's saved changes when it opened (a failed or timed-out request at launch), saving is paused rather than allowed to run. You'll see the message: "Couldn’t load this variation’s saved changes, so saving is paused to protect them. Reload the editor."
This guard exists because a save replaces the variation's saved change list: saving from an editor that wrongly shows zero changes would wipe your saved work. Reload the editor; once the saved changes load, saving resumes. The server enforces the same rule independently: an empty save without an explicit Clear all confirmation is rejected and the saved changes stay intact.
Variation pill stuck on "Loading variation…"
If the editor's startup data request stalls, the variation pill in the top toolbar shows "Couldn't load the variation" with a Retry button after a few seconds instead of staying on its loading state. Click Retry to re-request the variation's details: the pill is never permanently stuck. If retries keep failing, check the connection and the snippet detection causes above.
Editing a different variation
The editor works on one variation per session: the one you launched. To move to another variation, save your work, click Back in the top toolbar to return to the experiment's Variations step, and click Edit with Visual Editor on the variation you want next. The same applies after the copilot creates a variation for you ("Save as new variation"): the new variation is created and announced by name, and you open it from the dashboard to start editing it.
Consent mode
If you run the snippet in consent mode and the visiting browser hasn't opted in, the snippet stays inactive, and so does the editor. To author variations on a consent-gated site, either accept the consent banner in the editor browser, or temporarily set the snippet to always run for the staging environment you author against.
Anti-flicker interactions
Your install tag hides the page before the browser paints it, and the snippet reveals it again once changes are applied. Opening the editor is one of the paths that reveals the page straight away, because you need to see it to work on it. If you do see the editor panel attach while the page beneath stays blank, refresh the tab: the reveal on an editor launch is unconditional. See Anti-Flicker for the full lifecycle.
If you have a tricky issue we can't reproduce, capture a HAR file (Chrome dev tools → Network → right-click → Save all as HAR) and attach it to your support request. The HAR shows every request the snippet and editor made and is the fastest path to a fix.