Ten Horizon Variant Picker Gaps I Keep Finding in Audits

Twenty-one threads over the last year, spread across r/shopify and the Shopify Community, describe roughly the same Horizon variant picker problem in about ten different ways. On the stores I audit, the same failure modes show up in the same rough order: swatch grid overflow first, out-of-stock ambiguity next, then something weirder that turns out to be a quick-add modal issue or a Firefox script error. What follows is the catalog I have built from those threads and audits, and the notes I have on which fixes I trust.

I keep the list short because I have not been able to add anything genuinely new to it since August. Horizon has shipped updates. The list has not moved.

What I always check first: the swatch grid and the hero image

If a product has fifteen or more color values on a single option, the Horizon variant picker will stack every swatch into a grid with no maximum height. The grid grows down the page. The product image and the Add to Cart button slide off the bottom of the screen. A customer who clicks a swatch near the bottom of the grid has to scroll back up to see the product photo respond to their choice. Ploqo posted the fix on Shopify Community thread 659706 in August: constrain .variant-option__values to about 8.25rem of max-height with overflow-y: auto. It works. It should ship in the theme by default and does not.

.variant-option__values {
  max-height: 8.25rem;
  overflow-y: auto;
}

The second thing I check is the hero image. Horizon renders the first available variant's image in the gallery on page load. If a merchant photographs the same product in six colors, the visitor lands on whichever color is first in the backend order, regardless of which color they were pointed at from an ad or an email. Ploqo's fix on thread 661606 is a one-word edit in snippets/product-media-gallery-content.liquid: replace selected_or_first_available_variant with selected_variant. The gallery then defers to the product's cover photo until the customer picks a color. I have applied this on four stores. Price, stock, and Add to Cart behavior all stayed the same, exactly as Ploqo described. I have not tested it on a product where every image is variant-linked with no cover photo, and I would want a staging preview before deploying it there.

The three ways OOS variants misbehave

Out-of-stock variants misbehave in three ways at once inside the Horizon variant picker, and merchants keep discovering the failures one at a time.

First, the crossed-out sold-out swatch stays clickable. A customer can select it and get a grayed-out Add to Cart button. Second, the Theme Settings toggle labeled "Hide unavailable variants" does not actually hide them from the swatch grid in every Horizon version. Ecom_swift_LLC put it plainly on thread 661170: "Horizon has no built-in setting for this. It requires a code change (or an app)." Third, and this is the one that eats hours of a merchant's time, non-existent variant combinations look identical to real sold-out ones.

A merchant with a sparse product matrix, say a jacket that comes in three frame sizes and six colors but only in specific pairings, ends up with phantom slots for combinations that were never manufactured. Those phantoms render exactly like a genuinely sold-out variant. You cannot tell them apart from the picker alone. The DOM does distinguish them, though, and it took me embarrassingly long to notice: real sold-out variants carry a data-variant-id attribute because a Shopify variant record exists for them. Impossible combinations have data-option-available="false" but no data-variant-id. liquidshop.co posted the selector on thread 621419 back in May:

.variant-option__button-label:has(input[data-option-available="false"]:not([data-variant-id])) {
  display: none;
}

Hide the phantoms, keep the real OOS visible with strikethrough, and the picker suddenly makes sense. Momsstitchetti, who reported the same issue on Reddit and Shopify Community the same day, confirmed the fix on the thread.

If you are staring at your Custom CSS box and cannot tell whether you have the impossible-combination bug or the toggle-does-not-hide bug, the first 15 minutes with a help1 expert is free and that is usually plenty to point at the right file.

Two footnotes. The :has() selector needs Safari 15.4, Chrome 105, and Firefox 121 or newer. If your analytics show meaningful traffic on old Safari, the CSS approach will not cover you and a Liquid edit is needed instead. And there is a related autoselect bug on thread 565391: the picker preselects the first variant even when the first variant is out of stock, giving a fresh visitor a dead-looking product page on arrival. No confirmed code-free fix. I check every Horizon audit for a first-variant that is out of stock, because a store can look completely broken to a customer for one bad SKU.

Where Horizon silently hides the picker

Horizon has a design opinion that a variant picker with one value is redundant, so the Horizon variant picker suppresses itself entirely when a product option has only one value. That is correct for "Size: One Size." It falls apart for merchants who import products through apps like Reputon or through a CSV importer, because those apps often create a product with a single value for a color option, and the theme then silences the picker. The merchant sees a product page with no selector, googles "Horizon picker missing," and finds nothing that names the actual cause.

Maximus3 posted the fix on thread 674451 in August. In snippets/variant-main-picker.liquid, find the conditional {%- if product_option.values.size == 1 and variant_style != 'swatch' -%} and remove that block. Then set the picker style to Buttons in Theme Customizer. lelongdelajambe confirmed it: "The combination of removing the values.size == 1 block AND switching to Buttons mode works perfectly." I have deployed this once, and it did what it said.

The other silent hide is the image-swatch feature. Horizon can render uploaded photos as variant swatches, but only if the option is named exactly Color. Not Colour, not color, not Material or Finish or Style. Rename the option to anything else and Horizon falls back to text pills without a warning. rachaelwalker documented this on thread 568594 back in September 2025 and it has not been fixed. If your option must be named Colour for a UK brand or Finish for a hardware product, a metaobject-plus-Liquid path exists, but it ended in a file error in the last public attempt I could find. I would not commit to that path on a live store without a staging preview.

A help1 scan flags products with fifteen-plus values on a single option and pings the ones with sparse variant matrices, so you know before you spend an afternoon which products this catalog of gaps even applies to. Most Horizon stores I audit have four or five candidate products out of a catalog of forty.

The quick-add modal has its own failure class

Two bugs happen inside the quick-add modal that do not happen on the product page, and both are fresh, unmodified Horizon behavior. The Horizon variant picker rendered inside the modal is a different beast than the one rendered on the product page, even though the source Liquid is the same.

The first is a CSS isolation issue. Horizon wraps the variant picker's CSS inside a {% stylesheet %} tag in variant-main-picker.liquid. That tag compiles into the main storefront bundle during a full page load. It does not compile into the modal's dynamically fetched content. So the dropdown caret icon on the variant picker renders correctly on the product page and blows up to five times its normal size inside the quick-add modal. tim_tairli posted the structural analysis on thread 616156 in May. Fix: add the relevant CSS to snippets/quick-add-modal-styles.liquid, or move the whole stylesheet block into assets/base.css so it always compiles into the main bundle. Moving to base.css is the cleaner fix and the one I default to, with the caveat that a future Horizon update may change the source stylesheet and the moved copy will not receive that change.

The second is behavioral. On products with mixed stock status, where at least one variant is in stock and at least one is out of stock, the quick-add button collapses to a roughly four-pixel sliver at the right edge of the product card image. Wii reported this on unmodified Horizon and Dwell in thread 660012 in August. Ploqo diagnosed the cause: Horizon renders the "Add" button for the selected variant, and if that variant is unavailable, the disabled attribute collapses its visible content. The "Choose options" fallback button that should appear for multi-variant products never appears. The fix is a logic edit in snippets/quick-add.liquid to always assign quick_add_button = 'choose' for any product with more than one variant. Once applied, the sliver goes away.

Neither of these fires an error in the theme editor. You see them only on a live storefront on a collection page with quick-add enabled. If you have never opened your own store in an incognito window and clicked a quick-add on a partial-OOS product, you may have this bug and not know it.

Firefox, URL parameters, and things I have stopped worrying about

Two items in the catalog are open. One I still watch. The other I have moved on from.

The one I still watch is a Firefox-specific script error the Horizon variant picker throws from variant-picker.js. Astroimagery reported it on thread 623025 in May on an unmodified install. derek_lee proposed the cause as Firefox's custom element upgrade timing: the constructor runs before the child elements inside the custom element are parsed, so private field initialization touches DOM that is not there yet. tim_tairli pushed back, pointing out that the VariantPicker class does not appear to have explicit constructors, which would rule out derek_lee's mechanism. Neither posted a tested fix. Shopify has not commented on the thread. I have not confirmed the root cause on a live store either, because Firefox is a small enough slice of my clients' traffic that I have not devoted a debug session to it. If your Firefox traffic is meaningful, report the exact error text to Shopify support with a reference to thread 623025 before you try either proposed fix blind.

The one I have moved on from is the ?variant= parameter Horizon appends to every product card URL, even for single-variant products. Liam-Shopify confirmed on developer thread 22432 in October 2025 that this is intentional design. The canonical tag on the product page points to the clean URL, and Google respects it. The template edit merchants circulate that removes the parameter from href works for the product grid but does not extend to recommended-products widgets or recently-viewed sections, so a merchant who takes it on ends up chasing the same fix through half a dozen files. I do not think the URL cosmetic gain is worth the piecemeal template maintenance. Your view may differ if you rely heavily on link sharing for one specific SKU.

The shape under all ten of these is the same: Horizon makes a decision that would fit a tidy catalog and stays silent when the decision fires against a real one, which is why the list keeps getting longer even as each individual entry stays small enough to fix in a few lines apiece.