TLDR: If you're embedding a third-party form in a scrollable card on mobile, just make it fullscreen. Two scroll containers fighting each other never ends well — and on a cancer education business Finder, that fight was costing real patient leads.
The Setup
We built a cancer education business as an AI-powered chat that surfaces cancer treatment facilities and lets patients contact them in one shot.
The booking touchpoint is right inside the facility cards — inline, immediate, no redirect.
The idea was clean: HubSpot (their CRM and forms platform) iframe embedded directly in the card, pre-filled with whatever we knew about the user, one tap to submit.
Worked great on desktop.
The Wall
On mobile? Scroll nightmare.
The facility card lives inside a scrollable chat view. The HubSpot iframe has its own internal scroll. On a phone, those two containers fight for the gesture. You scroll the form, you scroll the page. You try to reach a field below the fold, you end up somewhere else entirely.
Worse: the submit button was clipping off the bottom. Users on smaller devices couldn't even see it without figuring out how to scroll inside a nested iframe — which most people don't think to try.
This is a cancer patient trying to contact a specialist. A confusing form isn't just a UX problem. It's a missed consultation lead, a lost webhook delivery, and a real person who didn't get the help they were looking for.
What I Tried First
I spent time tuning the iframe height and tweaking the card layout — trying to get the form to "fit" inside the card better.
It never really worked. You can't fix two competing scroll containers by making one of them taller. The physics don't cooperate.
The Fix That Actually Worked
Fullscreen overlay on mobile.
When a user taps the booking button on a phone, the form now expands to cover the whole viewport. No card context, no competing scroll. The HubSpot form owns the screen, the user's thumb moves through it like a native form, and the submit button is always reachable.
On desktop — where screen real estate is plentiful and the layout breathes — we kept the inline embed. The overlay only kicks in on mobile.
One other fix that burned an embarrassing amount of time: HubSpot pre-fill query params are case-sensitive, and they want lowercase.
I had mobilePhone. It needed to be mobilephone.
That's it. That was the bug. A capital P wiped out the pre-fill entirely and users were typing their phone number from scratch every time.
mobilephone. Save yourself the hour.
Why This Matters to Me
The broader lesson here is one I keep relearning: mobile scroll context is a constraint you design around, not through.
A form embedded in a scrollable container is fighting the user on mobile — full stop. The right fix isn't more CSS. It's giving the form its own context.
And when you're building something where every submission represents a patient looking for cancer care… you really can't afford to let a nested <iframe> stand between them and the help they're trying to find.