The report said “critical bug on the live tournament, the design dropdown is not working,” and the menu started at y=96 while both of its ancestors’ clip boxes ended at y=95.

A teammate posted that in Discord on a Thursday morning with a screenshot and a test site. The symptom was plain. Click Design in the site editor toolbar and nothing appears. The open questions were whether it failed to open, opened empty, or opened and didn’t apply, and whether it hit every page and every tournament site or only some.

Starting on the wrong control

An earlier ticket had already pointed at this area of the toolbar, and I started from it. It was the right neighbourhood and the wrong control. I spent the first part of the investigation on the wrong piece of the toolbar before the reproduction on the teammate’s site showed what was actually happening.

A menu that rendered and still showed nothing

Design is a title-nav dropdown. Toggle_TitleNav_Dropdown puts .open on the wrapper, and the handler worked every time. The menu rendered with all four items. So the handler was fine and the DOM was fine, and the screen still showed nothing.

I measured prod and a local build side by side:

menu box:                 y=96, height=168
.siteToolbar clip box:    y=56, height=39   (ends at 95)
.siteToolbar-items clip:  same

The menu began one pixel below where both clips ended, so 100% of it was outside the visible region of two ancestors that both had overflow:hidden. An overflow:hidden ancestor clips paint, and it also clips hit-testing.

That gave me a way to tell a dead handler from a clipped menu. I called elementFromPoint at the menu’s first item. On prod it returned the preview IFRAME sitting underneath. On the fixed build the identical point returned the “Colors & Background” span. The click was falling through the menu to the iframe, which is why nothing seemed to happen.

The same bug, fixed once already

This exact bug had already been fixed for the neighbouring “More” panel. The comment above .siteToolbar.is-open in the org-site stylesheet describes it word for word. The panel hangs at top:100%, entirely below the toolbar’s own 39px box, so the ancestor’s overflow:hidden cut it off, and the fix lifted the clip while the panel was open.

That fix keyed on .is-open, the class the toolbar sets for its own panel. The Design dropdown sets .open on its own wrapper, so the rule never fired for it. And .siteToolbar-items has a separate overflow:hidden that the earlier fix never covered at all.

So the first fix had a cost. It was scoped to one trigger class instead of to the condition that actually causes the clipping, which is any menu hanging below a 39px box while an ancestor hides overflow. The next dropdown to hang below that box hit the same wall, and this time it was reported as critical on a live tournament.

The fix and how I checked it

One CSS rule now lifts the clip on both ancestors while any title-nav dropdown is open, the same treatment .is-open gives the More panel.

I verified it end to end on a test site with the compiled bundle, using real mouse events instead of synthetic clicks, since synthetic clicks skip exactly the hit-testing that was broken:

  • Click Design, and the menu opens.
  • Click outside, and it closes. Close_TitleNav_Dropdowns still works.
  • Click “Colors & Background,” and it lands on the colors page with the right page title.
  • Narrow the window, and the overflow sync still moves Design into the More panel. Nothing spills, and at rest both clips are still hidden.

That last check matters because the clip exists for a reason. It hides the raw, unsorted items before overflow sync moves them into the More panel. Removing it outright would have fixed the dropdown and broken the narrow layout.

It shipped to production, and I repeated the same clicks on the live site.

Why “not working” pointed at the wrong suspect

“Not working” pointed at the handler, and the handler was innocent the whole time. The component did its job. The layout around it decided what got seen. When a menu seems dead, check whether its box is inside the clip boxes of its ancestors, and compare elementFromPoint on the broken build and a fixed one. If the answer changes, you have found a clip and not a bug in the click handler.