The Popup, the Chat Widget and the Sticky Bar Are Fighting Each Other
Install a discount popup, a chat widget and a sticky add-to-cart bar separately, each from a different vendor, and every one of them assumes it's the only thing living at the bottom of the screen.
On a desktop monitor that assumption mostly holds. On a 390 by 844 viewport, a fairly standard phone, it doesn't, and the three end up stacked on top of each other, on top of the button the customer actually came to press.
"None of the three teams responsible, the discount app, the chat vendor, the theme's own sticky-cart script, ever see each other's code, so nobody owns the collision."
Overlay collisions, by the numbers
3
Vendors fighting for the bottom of the screen who never see each other's code
390px
Standard phone viewport width where the collision actually shows up
15
Seconds to watch it happen on your own product page
The finding
Open a product page on your phone, scroll to where the buy button sits, and watch what appears over the next fifteen seconds without touching anything. A chat bubble claims the bottom-right corner. A sticky bar claims the full width of the bottom edge. A discount popup claims the centre of the screen, often with its close button rendered a few pixels below the visible fold.
Each app was built and tested in isolation, because none of the three vendors can see what the other two are doing after install. The result is an add-to-cart button that's technically on the page but not reachable without dismissing something first, on the device carrying most of the store's traffic.
Why sequence matters more than any single widget
The individual pieces aren't the problem, the order is. A discount shown before the customer has looked at a second product front-loads the offer and trains them to wait for it next visit. A discount shown after the sticky bar and chat bubble have already animated in gets buried under two other pieces of chrome and is never seen at all.
"The fix isn't removing widgets, it's deciding which one earns priority at which moment, and giving the rest a lower z-index or a short delay until the first has done its job."
This rarely shows up in a standard QA pass, because QA usually happens on a laptop where there's room for all three, and the conflict only appears at phone width.
A sequence that holds up
One order worth testing: sticky add-to-cart bar first, visible as soon as the buy button scrolls out of view, since it supports a purchase already in progress. Chat widget second, collapsed to an icon rather than an expanded bubble, since it's there for the minority who need it, not for everyone. Discount popup last and delayed, triggered on a genuine exit signal or real dwell time rather than page load, sized so its close control sits inside the visible viewport on a 390px-wide screen rather than below it.
Modern phones also expose the notch and home-indicator area to CSS through safe-area-inset properties. A sticky bar or popup that ignores this can render behind the home-indicator gesture bar on an iPhone instead of just above it, another way a control ends up unreachable that has nothing to do with which app loaded first.
Measure it yourself
- Load your own product page on a phone with the ad blocker off. Wait fifteen seconds without scrolling, and screenshot what's on screen.
- Count how many separate app overlays are visible at once. And check whether any control, the add-to-cart button, the popup's close icon, sits in a zone another widget is animating through.
The bottom line
More than one overlay live at once, or a close button you can't reach, is the fix to make before touching copy or discount depth on any of them.
At beCommerce, we check widget sequencing and overlay conflicts as part of every mobile UX review. If you want a hand untangling yours, book your free audit →.
Is your store making any of these mistakes?
We audit Shopify stores for exactly these kinds of conversion-killing patterns — the ones that have become normalised until you see them through a customer's eyes.
Book your free audit →
