Troubleshooting

The widget doesn't show up at all

• The snippet's survey identifier doesn't match a survey. Check that you copied the whole snippet from the Appearance tab without editing it — a hand-edited, partial or stale (deleted survey) identifier won't resolve to anything.
• A network problem. The visitor's browser couldn't reach rawquotes at all — a connection drop, a blocked request, and so on.
• An unexpected response from the server. The widget asked for the survey and got something back, but not a survey it could render.

All three cases look identical from the outside: the widget's script runs, asks for the survey, gets nothing usable back, and stops before drawing anything — including its floating launcher in floating mode. Nothing the visitor saw a moment ago disappears, because nothing was shown in the first place.

Your Content-Security-Policy blocks the widget's styling

The widget normally styles itself in a way that needs no relaxation of your page's CSP at all. It only falls back to a mechanism that requires style-src 'unsafe-inline' on browsers old enough to lack a newer styling API — practically, only outdated browsers by now. If your page's CSP is strict and you want the widget to render correctly on those older browsers too, add 'unsafe-inline' to your style-src directive. This is a real requirement for that fallback, not a workaround to avoid.

Your page's styles and the widget's styles don't affect each other

This is expected, not a bug. The widget renders inside its own isolated area of the page (a Shadow DOM), so your page's CSS can't accidentally restyle the widget, and the widget's own styles can't leak out and affect the rest of your page. Colors, shape and other visual settings are all controlled from the survey's Appearance tab instead of your page's stylesheet.

Inline mode: nothing renders where the container should be

In inline placement, the widget looks for its container element the moment its script runs. If that element isn't on the page yet at that point — for example because the snippet loads before the rest of the page's markup — the widget has nothing to attach to and gives up silently. Make sure the container element appears in your page's HTML before the widget's <script> tag, not after it.

Listening for what happened, if you're customizing the page yourself

If you or a developer working on your site want to react to widget events in your own code (for example, to hide a promotional banner once a visitor opens the survey), the widget exposes a small event queue:

<script>
  window.rawquotes = window.rawquotes || function () {
    (window.rawquotes.q = window.rawquotes.q || []).push(arguments)
  }
  window.rawquotes('on', 'render_error', function (detail) {
    console.log('widget did not render:', detail.reason)
  })
</script>

This is a developer-facing detail, not something most merchants need — it's mentioned here only because render_error's detail.reason (not_found, network or malformed) is the same distinction the sections above describe in plain language.