Troubleshooting
Виджет / Troubleshooting

Виджет не работает — что проверить

Реальные кейсы которые встречаются на проде. Каждый — что увидите, в чём причина, как починить.

FAB не появляется

Симптом

Вставили <script>-тег, открыли сайт — никакой круглой кнопки в углу нет.

Что проверить

1. Скрипт реально загрузился?

DevTools → Network → фильтр widget-bundle. Должен быть GET 200 (или 304 if-cached).

  • 404 — опечатка в URL (проверьте support.forestsnet.com/widget-bundle?ws=…) или некорректный ?ws= (workspace не существует / был удалён).
  • Запроса нет вообще — Adblock или CSP блокирует. См. ниже.
  • 500 — серверная ошибка на нашей стороне. Сразу пишите в саппорт, пришлите URL.

2. Console: ошибки?

Откройте Console. Типичные сообщения:

  • __SH_API_BASE not set — preamble бандла не сработал. Проверьте что URL запроса с ?ws=… и backend ответил 200 (см. предыдущий шаг).
  • WebSocket connection failed — норма пока визитор не отправил первое сообщение (backend отвечает 4401, бандл переподключается). Если ошибка персистит после первого сообщения — проверьте что api.support.forestsnet.com разрешён в CSP connect-src.

3. CSP (Content Security Policy)

Если ваш сайт настроил CSP — добавьте наши хосты:

http
Content-Security-Policy:
  script-src  'self' https://support.forestsnet.com 'unsafe-inline';
  connect-src 'self' https://api.support.forestsnet.com wss://api.support.forestsnet.com;
  img-src     'self' data: https://support.forestsnet.com;
  font-src    'self' data:;
  • script-src — для загрузки бандла. 'unsafe-inline' нужен потому что IIFE-loader инжектит inline-script тег. Если не хотите unsafe-inline — используйте прямой <script async src="…"> вместо loader-сниппета.
  • connect-src — для REST вызовов и WebSocket к нашему API.
  • img-src 'self' data: — операторские аватары + загруженные визиторами вложения приходят как data URLs.

4. Adblock

widget-bundle не сматчит ни один популярный фильтр (EasyList / EasyPrivacy / etc), но отдельные пользователи могут блокировать вручную. Если конкретный посетитель сообщает что у него виджета нет — пусть проверит Adblock / NoScript / Privacy Badger.

WebSocket падает / постоянно реконнектится

В Console видно WebSocket connection to wss://… failed каждые несколько секунд.

Норма (до первого сообщения)

Backend отвергает WS handshake с кодом 4401 пока не существует Contact с этим visitor_session. Контакт создаётся при первом сообщении. Бандл реконнектится opportunistic'но и подцепится сразу как только первое сообщение уйдёт.

Если визитор не собирается ничего писать (просто смотрит сайт) — это reconnect-loop в фоне, безвредный. Можно игнорировать.

Реальная проблема — Cloudflare блокирует WS

Если ваш сайт за Cloudflare с включённым «Bot Fight Mode» — WSS upgrade может рубиться как подозрительный трафик. Решение:CloudflareSecurityWAFSkip rule for api.support.forestsnet.com.

Один визитор → два контакта (cross-subdomain)

Посетитель пишет с example.com, потом переходит на app.example.com, и в дашборде это выглядит как два разных контакта с двумя параллельными беседами.

Причина

Visitor session ID хранится в cookie scoped по host. По умолчанию cookies не делятся между поддоменами.

Решение

Задайте cookie domain с лидирующей точкой:

html
<script
  async
  src="https://support.forestsnet.com/widget-bundle?ws=YOUR_WORKSPACE_UUID"
  data-cookie-domain=".example.com"
></script>

То же самое можно настроить в SettingsWidget BuilderConversationCookie domain — и сниппет на всех поддоменах останется одинаковый. data-cookie-domain выигрывает у конфига (удобно если стейдж и прод на разных доменах).

Visitor «забывается» после нескольких дней (Safari ITP)

В Safari посетитель возвращается через неделю и SupportHub показывает его как нового — старый ticket history не подхватывается.

Причина

Safari Intelligent Tracking Prevention режет client-set cookies до 7 дней. Cookie с visitor session ID удаляется → backend считает посетителя новым.

Решение

Виджет уже хранит ID параллельно в 5 уровнях (cookie + localStorage + sessionStorage + IndexedDB + legacy LS). При следующем визите ID поднимается из localStorage обратно в cookie. Если визитор вручную не очистил весь сайт data — он не «забудется».

Если хотите гарантировать сохранение между девайсами/браузерами — используйте identify с visitor_token из вашей CRM.

Бесконечная белая панель / FAB не открывается

Симптом

Кликнули по FAB — панель открылась пустая, белая, с иконкой загрузки которая не пропадает.

Причина 1: WebSocket недоступен и no-fallback

В корпоративных сетях WSS бывает заблокирован — виджет долго ждёт connection, не показывает контент. Console покажет WebSocket connection failed.

Воркэраунд: сейчас mandatory. Ждём решения от сетевого админа клиента. Long-polling fallback в roadmap.

Причина 2: повреждённый конфиг

Если в Builder вы вписали невалидный custom_css или сломанный JSON в advanced поля — preview покажет ошибку. На проде виджет всё ещё пытается отрендерить и падает в whitescreen.

Решение: SettingsWidget BuilderDiscard draft вернёт последнюю опубликованную версию. Или починить custom_css по сообщению об ошибке в preview.

Pre-chat форма не пропускается несмотря на identify

Причина

Pre-chat skip срабатывает только если переданы оба поля: email + name. Если только один — форма всё ещё спросит недостающее.

Решение

Передавайте оба:

js
window.SupportHub.identify({
  email: user.email,   // оба
  name:  user.fullName, // обязательны для skip
});

Powered by SupportHub не скрывается

Причина

Тоггл Hide Powered by в Brand-секции plan-gated — доступен только на тарифах с фичей custom_branding. На бесплатном плане отображается заблокированным.

Решение

SettingsBillingUpgrade на тариф который включает custom_branding. После апгрейда тоггл разблокируется автоматически.

Изменения в Builder не доезжают до посетителей

Причина

Builder сохраняет в draft. Прод-виджет видит толькоопубликованную версию. Кнопка Publish в правом верхнем углу промотирует draft в эфир.

Cache

Bundle кешируется браузером и CDN на 60 секунд. Если опубликовали — посетители получат новый конфиг при следующем заходе через минуту. Hard-refresh не нужен.

Reactions / inline keyboard не работают

Причина

Эти фичи отключены в дефолтном конфиге для нового workspace.

Решение

SettingsWidget BuilderConversation → включите Reactions enabled и Inline keyboard enabled. Опубликуйте.

Что-то ещё?

Не нашли свой кейс? Напишите нам через сам виджет на support.forestsnet.com — добавим в этот раздел.

Была ли страница полезной?