Anyone else experiencing this, the UI for the chat interface iframe seems to be missing it’s cursor pointer events.
Abit of context, the iframe is generated inline with the conversation sdk.
Hi @RubixVi i 
Thanks for flagging this — missing cursor/pointer events in the chat iframe can be especially frustrating when everything else looks like it’s rendering correctly.
I’d like to pull in a few Community members who’ve worked closely with the Conversations SDK and embedded chat behavior.
Hi @danmoyle @Shae_Taylor @ChristinaKay — hope you’re all doing well! Have any of you run into pointer or cursor issues with inline-generated chat iframes? Curious if this has come up due to styling, overlays, or SDK quirks in your experience.
Appreciate any insight you can share here.
Victor
@RubixVi I haven’t personally experienced this UI issue, and I don’t see it often. I did a quick cursory search and it is the kind of edge‑case issue that does show up for some custom SDK embeddings.
With that said, I think it might be happening because (as I understand it within my limits), when the chat iframe is generated via the Conversations SDK and embedded inline, custom CSS or parent container styles can inadvertently introduce pointer-events: none or overlay elements that block interaction, possibly causing the cursor to behave as though the iframe is non‑interactive.
Similar SDK/iframe posts I found (like this one) mention that reopening the widget or changing tabs temporarily fixes interaction issues, which points to state/initialization quirks in certain SDK versions rather than a platform‑wide bug.
So what I’d suggest doing next is:
- Inspect the parent containers and overlays around the iframe (DevTools) to see if any have pointer-events: none or high z-index values sitting above the iframe.
- Test the same chatflow using the standard HubSpot embed snippet (without the inline Conversations SDK integration); if it works there but not in your SDK implementation, that narrows it to your embedding pattern or a Conversations SDK regression worth escalating to HubSpot support.
Here’s a HubSpot KB article for reference. I hope that helps!
Moderator note: While this solution may not address the original poster’s specific situation, it could be helpful for other community members facing similar challenges.
Unfortunately, that’s not the reason behind it.
Hi @RubixVi — thanks for confirming this isn’t caused by CSS or overlays.
At this point, it would help to narrow down whether this is an SDK regression or an environment-specific issue. If you’re able, could you share a few details so others can try to reproduce it?
- Browser(s) and versions where this occurs
- OS
- Whether it happens consistently or only after certain state changes (reload, navigation, reopening chat, etc.)
- Conversations SDK version in use
- Whether the issue also occurs with the standard HubSpot embed snippet (non-SDK)
If this turns out to be reproducible beyond a single setup, I’d recommend posting it to the Ideas Forum as well, requesting clearer documentation or fixes around pointer-event handling for inline-generated chat iframes via the Conversations SDK. That’s the best channel for getting product visibility on potential SDK/UI regressions like this.
Best, Victor
<>
<Script id="hs-conversations-settings" strategy="afterInteractive">
{`
window.hsConversationsSettings = {
inlineEmbedSelector: "#hubspot-chat",
loadImmediately: false
};
`}
</Script>
<Script
id="hs-script-loader"
src={`https://js-ap1.hs-scripts.com/${hubSpotID}.js`}
data-privacy="true"
strategy="lazyOnload"
/>
</>
Above is part of how I load up hubspot.
It is then injected via
<div
id="hubspot-chat"
className="pointer-events-auto right-0 bottom-0 left-0 [&_iframe]:h-105.5"
/>
It is controlled on page.
const handleClick = () => {
const widget = window.HubSpotConversations?.widget
setIsOpen((prev) => {
if (!widget) {
window.hsConversationsOnReady = window.hsConversationsOnReady || []
window.hsConversationsOnReady.push(() => {
window.HubSpotConversations?.widget?.open()
})
return true
}
if (prev) {
widget.remove()
hubspotref.current = false
return false
} else {
if (!hubspotref.current) {
hubspotref.current = true
widget.load()
}
return true
}
})
}
With non inline, the ui cursor events are fine so via the standard
<Script
id="hs-script-loader"
src={`https://js-ap1.hs-scripts.com/${hubSpotID}.js`}
data-privacy="true"
strategy="lazyOnload"
/>
Which renders the default chat bubble.
Browser tested: Chrome, Edge, Comet.
Not sure how OS is related, however both Linux and Windows.
Hey @RubixVi ! thank you for your patience while we find a solution for your issue.
I want to tag more experts here to see if they can help out. Hey @karstenkoehler @SkeeStylus @RubenBurdin. Would you kindly share your thoughts here? Any insights will help!
Thanks in advance
Victor