DEV Community: zhen

Capturing custom dropdowns is harder than you think: lessons from building a form recovery extension

zhen — Fri, 09 Oct 2026 18:05:01 +0000

Native <select> elements are easy. You read .value, you set .value, done. The problem is that half the web doesn't use native selects anymore.

Every UI framework has its own dropdown: React Select, MUI Autocomplete, Ant Design Select, custom-built divs with ARIA roles. They look like dropdowns, they act like dropdowns, but under the hood they're divs, spans, and JavaScript state that the DOM doesn't know about.

I ran into this building FormSafe, a Chrome extension that saves what you type in forms so you can restore it after a tab crash. Text inputs were straightforward. Custom dropdowns nearly broke the whole project.

Why custom dropdowns are hard to capture

A native select stores its state in the DOM. A custom dropdown stores its state in JavaScript. When you need to save "what did the user pick," you're asking two different questions:

What does the DOM show? (the visible label, e.g. "California")
What does the app think is selected? (the internal value, e.g. "CA")

For restoration, you need #2. But #2 lives in a closure, a React state hook, a Vue ref — somewhere your content script can't reach.

Approach 1: Read the visible text (fragile)

The naive approach: find the element that displays the selected value, save its textContent.

This breaks immediately. The visible text is "California" but the form expects "CA". On restore, you set the text to "California" and the app's internal state still says nothing is selected. Submit the form and the server gets an empty value.

Worse: some dropdowns show different text than the value (e.g. displaying "CA — California" but storing "CA"). Text matching is a guessing game.

Approach 2: Simulate the clicks (slow but honest)

What actually works: on restore, programmatically reopen the dropdown and click the right option, the same way a user would.

The sequence:

Find the dropdown trigger element (the thing the user clicks to open it)
Dispatch a real click event on it
Wait for the options list to render (MutationObserver, with a timeout fallback)
Find the option matching the saved value
Dispatch click on that option
Verify the selection took effect

This works because you're going through the same code path as a real user interaction. The framework's internal state updates correctly because as far as it knows, someone actually clicked.

The downside: it's slow. Each dropdown takes 200-500ms to restore (open, wait, click, verify). A form with 10 custom dropdowns takes a few seconds. Acceptable for a recovery flow, terrible for anything real-time.

Approach 3: Framework-specific hooks (powerful, unmaintainable)

You can reach into React's fiber tree, or Vue's component instance, and read/write state directly. I've seen extensions do this.

I decided against it. Every framework version changes internals. You'd be maintaining a compatibility matrix instead of building features. The click-simulation approach is framework-agnostic — it doesn't care if it's React 18, Vue 3, or vanilla JS.

The edge cases that keep me up at night

Async option loading. Some dropdowns fetch options from an API when opened. On restore, you open the dropdown, the options aren't there yet, your MutationObserver fires on the loading spinner. You need to wait for the actual options, with a sane timeout.

Multi-select with chips. The selected values render as removable chips. Restoring means clicking each option individually, then verifying the chip count matches.

Dependent dropdowns. Country → State → City. You must restore them in order, waiting for each to populate the next. Get the order wrong and you're selecting "California" in a city dropdown.

Virtualized lists. Long option lists only render visible items. The option you need might not be in the DOM until you scroll. This one I still don't handle perfectly.

What I'd tell someone starting this today

Don't try to be clever. Simulate user interactions. It's slower and less elegant than reaching into framework internals, but it works across every framework and doesn't break when React ships a new version.

And be honest about failures. If a dropdown can't be restored reliably, tell the user which one. Silently filling in wrong data is worse than admitting a gap.

This is from building FormSafe, a free Chrome extension for form recovery. The dropdown problem was the hardest part by far — text inputs took a day, dropdowns took two weeks.

Silence is distracting. Music is distracting. So I built a third option.

zhen — Fri, 09 Oct 2026 17:28:22 +0000

I work from home. Complete silence makes my brain invent problems to worry about. Music with lyrics hijacks the language part of my brain — I'll be halfway through a function and realize I've been mentally singing along for five minutes.

There's actual research on this. A 2012 study found that moderate ambient noise — around 70 decibels, roughly coffee shop level — boosts creative thinking compared to both silence and loud environments. The theory is that a little bit of distraction forces your brain to work slightly harder to focus, and that extra effort spills over into more abstract thinking.

So the science says: don't work in silence, don't blast music, sit in a coffee shop. Great. Except I can't work from a coffee shop every day.

What I tried before building

YouTube "10 hours of rain sounds" videos. They work until an ad for car insurance shatters your flow state at hour 3. YouTube Premium would fix it but I'm not paying monthly to listen to rain.

Noisli, myNoise, the usual suspects. Some are good. Most want a subscription for the full sound library, or they're web-only which means keeping a tab open, or the mobile app is a completely separate purchase.

Spotify focus playlists. They all start sounding the same after a week, and eventually the algorithm decides I want lo-fi hip hop with the exact same four chords on loop.

What I actually wanted

Something stupidly simple: pick a few sounds, set their volumes, forget about it. Rain a little louder than the cafe chatter. Brown noise underneath everything. No account. No monthly fee. No tab I have to keep open.

So I built Drift. Chrome extension, sits in the background:

12 natural sounds. Rain, thunder, cafe, forest, fireplace, brown/pink/white noise, that kind of thing. Each with its own volume slider, so you're actually mixing, not just picking a preset.

Runs without a tab. It's a proper extension, not a website pretending to be an app. Close everything, the sound keeps going.

No account, no subscription. I built this for myself. I'm not building a SaaS around rain sounds.

The mix that works for me

Rain at 70%, distant thunder at 20%, brown noise at 30% underneath. Loud enough to fill the silence, quiet enough that I forget it's there after ten minutes. That's the sweet spot — if you're consciously noticing the sound, it's too loud.

Everyone's different though. Some people swear by cafe + fireplace. My friend does forest + rain and claims it's the only way he can write.

Try it

It's free. If the default mixes don't work for you, play with the sliders — that's the whole point.

Get Drift on the Chrome Web Store

Curious what combos other people land on. The "right" background noise seems weirdly personal.

Your browser doesn't save what you type. I learned that twice in one month.

zhen — Wed, 07 Oct 2026 16:39:29 +0000

The second time, I just sat there staring at an empty form for a full minute. Forty minutes of job application — work history, cover letter, those miserable "describe a time you demonstrated leadership" essays — gone because a tab crashed.

Session restore brought back the URL. Not a single word I typed.

The thing nobody tells you

Form data lives in the DOM. When the renderer process dies, your input dies with it. The browser has no idea what you wrote. It never did.

"But autocomplete—" No. Autocomplete knows your name and email. It doesn't know about the paragraph you just wrote explaining why you're a good fit for a job.

"But the site should autosave—" Some do. Google Docs does. Your bank's loan application? The government portal? The janky ATS that 90% of companies use? Absolutely not.

Lazarus is dead and nothing replaced it

If you've been around, you remember Lazarus Form Recovery. Massive user base, did exactly this. Got pulled from the Chrome Web Store years ago and never came back.

I looked at what's out there now. Abandoned projects. Or worse — tools that read everything you type and phone home to someone's server. For a form recovery tool, that's a hard no from me.

So I built my own.

FormSafe: what I built and the calls I'd defend

Chrome extension. Watches what you type in forms, saves it locally as you go. Tab crashes, you click the icon, hit restore, done.

100% local. No server, no account, no analytics. I don't want your half-written job applications and you shouldn't want mine. The tradeoff: no cross-device sync. I'm fine with that.

Passwords are never saved. Not a toggle, not a setting. The code just doesn't do it.

30-day auto-expiry. Otherwise it becomes a graveyard of drafts you'll never open again.

Honest about failures. This one's important. Some custom JS dropdowns are genuinely hard to capture. If a field can't be restored reliably, FormSafe tells you which one — instead of silently filling in wrong data and letting you submit a broken application.

Try it, break it, tell me

It's free. No account, no catch. I built it because I needed it, and I'm still finding edge cases — every site builds form widgets differently.

If something doesn't restore right, I want to hear about it.

https://chromewebstore.google.com/detail/deklfkdfegechjgmpjinlghcllgojhni