After installation on our internal test website, the dialog keeps spinning after starting. The network status shows "pending" for the initialization process. IT confirmed that it's not blocking botpress traffic. What could be causing this? Additionally, the console displays the following error:

inject.js:346

DialogContent

requires a

DialogTitle

for the component to be accessible for screen reader users. If you want to hide the

DialogTitle

, you can wrap it with our VisuallyHidden component. https://cdn.discordapp.com/attachments/1519957075935887430/1519957076057657384/C3395F3C-8340-44FE-805C-36511E6EA6C6.png?ex=6a3f71d6&is=6a3e2056&hm=1ad22c65b20d0a578d7b16306aa3ae679f2798ffc904400e473115fbe4cd1c96& https://cdn.discordapp.com/attachments/1519957075935887430/1519957076527550575/F21B0658-A96D-4936-84D9-46FC1D4FC8BC.png?ex=6a3f71d6&is=6a3e2056&hm=a87e03e8b1205c25961419a5f0602583e9b7d39c0555632324decb0d184a4bc6&

The spinner is happening because the webchat opens a streaming connection (Server-Sent Events) to load, and it only finishes initializing once that stream "opens." That's the request you're seeing stuck on "pending", pending is actually normal for a streaming connection; the problem is it never opens and starts streaming. Since this is on your internal test site, the most likely cause is a corporate proxy / firewall / SSL-inspection gateway (e.g. Zscaler, Netskope, Palo Alto, or a security web filter) that's buffering the streamed response instead of letting it flow through in real time. Important detail: "allowing Botpress traffic" isn't quite the same thing, the domain can be allowlisted while the streaming response still gets buffered, which is exactly what breaks it. Two quick things to confirm it: Open the site from a device off the corporate network (e.g. phone on cellular/hotspot). If the chat loads instantly there, that confirms it's the network gateway. In DevTools, check the /conversations/.../listen request, it should be 200 with Content-Type: text/event-stream and stay open streaming data. The fix is on the network side: ask IT to let SSE (text/event-stream) responses pass through un-buffered for the Botpress domains, and to bypass SSL/streaming inspection for those endpoints. On an nginx-type proxy that's proxy_buffering off; / honoring X-Accel-Buffering: no. One more thing, the DialogContent requires a DialogTitle console message is unrelated and harmless (just an accessibility warning), so you can safely ignore it. 👍