Why the button ignores your clicks

What you saw

A form that renders perfectly, logs nothing, throws nothing — and refuses to respond. The button won't fire, the inputs won't focus, the dropdown won't open. Logging inside handleBake proves the handler never runs: the click isn't being swallowed by your code, it's never arriving in the first place.

That combination — visually fine, behaviorally dead, console silent — is the signature of a pointer-events / overlay trap. The event isn't lost. It's landing on something you can't see.

What's actually happening

The page renders a decorative Aurora layer for the warm "freshly baked" glow:

{/* warm ambient glow behind the form */}
<Aurora />

And the CSS that positions it:

.aurora {
  position: fixed;
  inset: 0;        /* top:0; right:0; bottom:0; left:0 — covers the whole viewport */
  z-index: 10;     /* lifted above the form, which has no z-index of its own */
  overflow: hidden;
}

That's a single full-screen element stretched edge to edge and stacked on top of the form. The comment says "behind the form," and that was the intent — but position: fixed plus z-index: 10 over a card that creates no stacking context of its own puts it firmly in front.

Here's the part that makes it invisible: a transparent element still catches the mouse. The aurora's own background is empty — you can see the entire card straight through it — but transparency is a paint property, not a hit-testing property. As far as the browser's "what did I click?" logic is concerned, there's a solid sheet of glass covering the viewport. Every click, every focus attempt, every drag lands on the glass and stops there. The form underneath never hears a thing.

You can prove it without touching the React. Open the console and ask the browser what's actually under a point on the button:

const r = document.querySelector('.bake').getBoundingClientRect()
document.elementFromPoint(r.x + r.width / 2, r.y + r.height / 2)
// → <div class="aurora">  ❌  (you wanted <button class="bake">)

The element at the button's coordinates isn't the button. It's the aurora. That's the whole bug in one line.

The fix

The decoration should be seen and never touched. Tell the browser to let the mouse fall straight through it:

.aurora {
  position: fixed;
  inset: 0;
  z-index: 10;
  overflow: hidden;
  pointer-events: none;   /* ✅ clicks pass through to whatever is underneath */
}

pointer-events: none makes an element (and its children, unless they opt back in) completely transparent to hit-testing. It still paints, still animates, still glows — it just stops existing as far as the mouse and keyboard are concerned. Re-run the elementFromPoint check and you'll get the <button> back.

There's a second, equally valid fix: honor the comment and actually put the layer behind the content, so it never overlaps in the first place:

.aurora { z-index: -1; }   /* sit behind the form instead of over it */

Either works here. pointer-events: none is the more robust habit for decorative overlays, because it keeps working even if the stacking order shifts later or the layer genuinely needs to sit above some content (a glow over a hero image, say). Reach for z-index: -1 when the thing is purely a background and you're confident nothing should ever sit beneath it.

What you should not do is delete the aurora or rip out the styling to "make the buttons work." That fixes the symptom by removing the feature. The decoration was never the problem — its failure to get out of the way was.

The bug class

This is the invisible-overlay / pointer-events trap: a positioned element covers interactive content and intercepts pointer and keyboard events, even though it's visually transparent or empty. It's one of the most common CSS-layout bugs in real apps, and one of the most disorienting, because your JavaScript is flawless — the breakage lives entirely in the paint-and-stacking layer, where most people don't think to look when a click handler "doesn't fire."

The usual suspects:

• A full-bleed decorative layer — gradients, "aurora"/"glow" effects, particle canvases, watermark logos — positioned over the page without pointer-events: none.
• A modal or drawer backdrop that didn't unmount. The dialog closed, but its position: fixed; inset: 0 scrim is still in the DOM with opacity: 0, silently eating every click on the page behind it. Classic "the whole app froze after I closed that popup."
• A ::before / ::after pseudo-element used for a visual flourish that quietly covers its parent's clickable area.
• A sticky header or hero with a negative margin that extends its hit area over the content below it.

How to spot it in the wild:

• The handler never runs. Put a console.log at the very top of the handler. If it doesn't print, the event isn't reaching your code — look above the element, not inside it.
• document.elementFromPoint(x, y) at the dead control's coordinates. If it returns something other than the control, that something is your culprit. This is the fastest possible diagnosis.
• Inspect-on-hover. In the elements panel, move the mouse over the dead area and watch which node highlights. A surprise full-screen div lighting up is the tell.
• The "everything is dead" smell. When one button is broken, suspect the button. When every control on a region stops responding at once but still looks fine, suspect a layer sitting on top of all of them.

The durable habit: any element that exists only to be looked at should declare pointer-events: none. Decorations, overlays, glows, badges, watermarks — if it has no handlers and no inputs, it has no business catching the mouse. Make "is this purely visual?" trigger "then it shouldn't be clickable," and this entire class of bug disappears.