Chasing a Shopify Cart Drawer Freeze Through Three Apps

Open Google Analytics for a store you're auditing. Filter the last 30 days. Compare Add-to-Cart clicks against Begin-Checkout clicks. If the two numbers are close but revenue isn't, and the merchant is running a modern Shopify theme with a slide-out cart, there is a specific bug I want you to check for. I lost an afternoon to it last month and I would rather you not lose the same afternoon.

The symptom nobody could explain

The store I was helping had a clean funnel and terrible math. 69 add-to-cart events matched by 69 checkout-button clicks in one seven-day window. A handful of orders.

Customers don't quit that consistently. Something in the plumbing was breaking every attempt.

The merchant had already told Shopify Support the button was fine. DevTools showed no console error. The page didn't crash. On desktop the checkout button worked. The complaint was mobile Safari on one specific theme setting: the drawer, not the cart page.

I asked for a session replay. Microsoft Clarity had one, and the replay was worse than I expected. The customer taps Checkout in the drawer. Nothing visible happens. Fourteen seconds pass. Then the screen redirects, but not to Shopify's checkout URL. To the product page they came from, as if the drawer had quietly given up.

What I checked first

I started where any Shopify developer starts. Theme settings. In Online Store, Themes, Customize, Cart, the shopify cart drawer setting was on. Clicking Checkout inside the theme editor's preview worked. That eliminated theme settings.

Then Liquid. The cart-drawer section in this theme (Prestige 11.1.0) looked untouched. No custom snippet had been rendered inside it. The theme diff against the vendor's baseline was clean.

Then browser. I reproduced the failure in Chrome mobile emulation, then on a real iPhone. Same 14-second freeze, same silent redirect. Not a browser bug.

Then Shopify status. Green. Not Shopify.

At this point I was three hypotheses deep and none of them had explained a thing.

Why my first three guesses were wrong

Guess one was a single-app failure. The store had three cart-adjacent apps installed: one for the slide-out, one for the shipping progress bar, one for in-cart bundles. I disabled the bundles app. Reload, add to cart, click Checkout. Same freeze.

Guess two was the shipping progress bar. That app fetches a real-time cart total to decide whether to render its "spend $12 more" bar. I disabled it too. Same freeze.

Guess three was the slide-cart app itself. This is where I got embarrassed. I could not disable this app the way I disabled the others. It had registered itself as the cart drawer handler, and toggling it off in the app admin did not remove its hooks. The native drawer refused to come back until vendor support intervened. I learned later from a June 2026 Shopify Community thread that another merchant hit the exact same lock-in. Shopify cart drawer replacement apps quietly own the drawer even when disabled, which is its own problem for another post.

Where the trail went cold

I opened DevTools' Network tab and filtered to only the requests fired when the user clicks Checkout inside the drawer. On a working desktop session, three requests fire in about 200ms, then the browser navigates to /checkouts/…. On the mobile session that froze, four requests fired, then a fifth, then a sixth. The sixth one hung.

The sixth request was a call to a domain I didn't recognize. It kept returning a CORS error, then retrying. Then retrying again. Fourteen seconds of retries.

That domain no longer had anything running on it. It was a dead endpoint. But something was still calling it, from inside the drawer, before allowing checkout navigation to proceed.

The clue I almost missed

I had been treating the three visible apps as the only suspects. That was the mistake.

I checked Apps in the Shopify admin. Three cart apps, matching the three the merchant paid for. I also checked the theme.liquid <head> and the additional-checkout-scripts snippet. Both looked clean.

Then I checked the App Embeds panel in Theme Customization. Two of the embeds referenced apps that were no longer installed. Uninstalled months ago. Their embed blocks were still there, and the code they injected was still executing.

For anyone who has read our Shopify app uninstall leaves code behind piece, this is the same pattern in a new coat. Shopify does not remove app embed blocks or ScriptTag registrations on uninstall. The merchant thinks the app is gone. The storefront still ships their JavaScript.

One of those ghost embeds was a discontinued cart-abandonment tool. Its pre-checkout script tried to POST to its old tracking endpoint before letting the user navigate. Endpoint gone, retries on. That was the 14 seconds.

What it actually was

Three simultaneous things caused the freeze.

The first was Shopify's own event architecture. When a user taps Checkout inside a Shopify cart drawer, most modern themes fire a sequential chain of pre-navigation callbacks: tracking pixels, app-supplied cart snapshots, third-party checkout extensions. Every subscriber to that event has to complete before the checkout URL is navigated to. The chain is invisible in DevTools unless you know to look for it.

The second was app residue. Even after uninstalling an app, Shopify preserves any theme embeds it registered. The app's code keeps running from the merchant's theme, pointing at endpoints that no longer respond.

The third was network conditions. On a slow mobile connection with a strict CORS-blocking origin, one dead endpoint can hold the whole checkout chain hostage. Add an ad blocker (Safari's Content Blocker or a mobile browser extension) and a live tracking pixel can hang the same way. On desktop with a fast connection, the retries fail quickly enough that the silent redirect never happens visibly. That is why the merchant couldn't reproduce it from their own laptop and Support couldn't reproduce it at all.

I want to be honest about the parts I still don't fully know. I have not confirmed which specific event name each theme uses for its pre-checkout chain. Some themes fire cart:submit; some fire nothing named at all and just chain callbacks internally. I have not tested this pattern against the Spring '26 standard storefront events either. Shopify shipped shopify:cart:lines-update and Shopify.actions.updateCart on June 17, 2026, and if apps adopt them this class of freeze should become rarer. As of my audit, none of the three cart apps on this store had migrated.

The wider pattern

That store was not unusual. It is the shape most merchants running a shopify cart drawer with more than two apps end up in.

The native drawer in Horizon, Savor, and Pitch, three of the most-installed themes since Horizon shipped, has no shipping progress bar, no upsell, no cross-sell, and no bundle line. Merchants launch, notice the gap, and start filling it with apps. By month two the store is spending $100-140 a month across three apps that all reach into the same DOM element.

A Reddit thread from May 2026 captures the frustration exactly. A merchant paying $140/month for a slide-cart app, a progress-bar app, and an in-cart bundles app describes them as clashing with each other and injecting "tons of heavy JavaScript that slows my mobile speed to a crawl." Forty comments. No accepted solution. Three different camps of advice: consolidate into Vitals, custom-code Dawn, or switch themes to Focal.

The three-camp split is telling. It means the community itself hasn't converged on a reliable stack. And the reason it hasn't converged is architectural. Shopify cart drawer apps come in one of two types: injection apps that add a widget inside the native drawer, and replacement apps that swap the drawer for their own. Replacement apps conflict with every other replacement app. UpCart, for example, substitutes /cart/add.js with /cart/add.js?upcart=1, which breaks Klaviyo's Added-to-Cart tracking because Klaviyo listens on the standard endpoint. Neither vendor is wrong; they are both trying to own the same shared resource.

Horizon adds a second layer to this. Its cart drawer is a web component inside Shadow DOM. Apps written for the flat-DOM pattern that worked in Dawn cannot reach past the Shadow boundary. They install successfully, appear in the admin, and do nothing on the storefront. If a developer also assumes the drawer fires on cart:updated (past tense) rather than cart:update (present tense), which is what Cursor and ChatGPT keep generating, that is another silent failure most merchants never diagnose.

What I did about it

For that specific store, I did four things.

Switched from cart drawer to cart page in theme settings. A cart page renders as a normal navigation event and skips the drawer's callback chain entirely. Conversion recovered within a week. The Shopify Community thread that documented the SmokeEraser case landed on the same fix.
Audited App Embeds and ScriptTag entries. Removed embed blocks for the three uninstalled apps. This is a manual pass in Shopify admin; there is no batch UI for it. If you want a diagnostic that flags this automatically, our free store scanner checks embed blocks against installed apps and reports the mismatch.
Consolidated three cart apps into one. Vitals was the destination for this store, mostly because it handled the progress bar, in-cart upsell, and bundles the merchant needed. This is not a blanket recommendation. Vitals is not the right answer for every store; it was the right answer for this one.
Wrote the merchant a small checklist for future app installs. Check whether the app is injection-type or replacement-type before installing. Confirm explicit Horizon compatibility if the store is on Horizon. Test the full add-to-cart-through-checkout flow on a real mobile device after each install, not just desktop.

If you are looking at your own Analytics right now and seeing a wide gap between add-to-cart and completed checkouts, and you have more than two cart-related apps installed, the first 15 minutes with a help1 expert is free and that is usually enough to know whether you are in the same shape as this store. Bring the App Embeds screen and, if you have it, one mobile session replay.

The take

I keep coming back to what this freeze actually is: not a Shopify bug and not one app being badly written, but the emergent behavior of a shared drawer that Shopify decided not to build features into, and an app ecosystem that has been filling the gap with mutually incompatible plugins for years. If a native drawer is failing you, install fewer apps before you install a fourth one.