---
title: "Two overflow:hidden Ancestors and a Click That Hit the Iframe"
canonical: https://dxdev.com/blog/css-ancestor-clipping-false-bug/
datePublished: 2026-08-28
---
The report said "critical bug on the live event, 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.

## Starting on the wrong control

An earlier ticket had already pointed at this area of the toolbar, so we started from it. It was the right neighbourhood and the wrong control. We spent the first part of the investigation on the wrong piece of the toolbar, and only 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. The handler was fine, the DOM was fine, and the screen still showed nothing.

We 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. That put 100% of it 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 us a way to tell a dead handler from a clipped menu. We 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, already fixed once

This exact bug had been fixed before, 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. 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 event.

## The fix and how we 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.

We verified it end to end on a test site with the compiled bundle. We used real mouse events rather than 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 we repeated the same clicks on the live site.

## What "not working" actually meant

"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.

If a menu seems dead, check whether its box sits inside the clip boxes of its ancestors, and compare `elementFromPoint` on the broken build and a fixed one. A fix scoped to one trigger class leaves the cause in place, and the next component that meets the same condition fails the same way.