Issue #13 — “The Dropdown That Refused to Drop”
Issue #13 — “The Dropdown That Refused to Drop”
🌼 Lady Daisy Bug: A QA & Test Automation Digest with Personality
Welcome to Lady Daisy Bug — your new favorite corner of the internet where quality assurance meets charm, code, and character. Whether you’re debugging tests in the moonlight or strategizing a flawless regression suite before your first coffee, this newsletter’s for you.
I’m your host, Lady Daisy Bug — part test whisperer, part bug wrangler, and full-time believer in thoughtful testing. Each issue will blend bite-sized insights, automation tips, and a little QA storytelling to brighten your day (and your pipelines).
Let’s squash some bugs — and do it in style.
🌟 Bug of the Week: The Dropdown That Refused to Drop
🕵️ Story:
I was testing a profile update flow. Everything looked fine: text fields filled, checkboxes clicked, progress smooth… until I reached the country selector.
A shiny dropdown. One click away.
Except, no matter how many clicks, taps, or key presses I tried — the menu just sat there. Stoic. Motionless. Dropdown in name only.
🔍 Symptoms:
- Dropdown element was visible but not interactable.
- Manual testing sometimes worked — automation never did.
- No error messages, just a silent refusal to open.
🧠 Root Cause:
The culprit wasn’t my test. It was CSS.
The dropdown was wrapped in a parent 𝚍𝚒𝚟 with 𝚙𝚘𝚒𝚗𝚝𝚎𝚛-𝚎𝚟𝚎𝚗𝚝𝚜: 𝚗𝚘𝚗𝚎 applied (a styling leftover from a loading state). The devs had forgotten to re-enable it. So visually, the dropdown looked ready… but functionally, it was blocked from receiving clicks.
🛠️ How I figured it out:
- Added a debug step with JS click: 𝚎𝚕𝚎𝚖𝚎𝚗𝚝.𝚌𝚕𝚒𝚌𝚔() still failed.
- Ran 𝚐𝚎𝚝𝙲𝚘𝚖𝚙𝚞𝚝𝚎𝚍𝚂𝚝𝚢𝚕𝚎 in console — saw 𝚙𝚘𝚒𝚗𝚝𝚎𝚛-𝚎𝚟𝚎𝚗𝚝𝚜: 𝚗𝚘𝚗𝚎.
- Confirmed the overlay div wasn’t being removed after page load.
✅ Fix:
- Devs patched the CSS: 𝚙𝚘𝚒𝚗𝚝𝚎𝚛-𝚎𝚟𝚎𝚗𝚝𝚜 now toggles correctly after load.
- I updated the test with an assertion to catch invisible blockers:
assert driver.execute_script(
"return getComputedStyle(arguments[0]).pointerEvents", element
) != "none"
So next time, the test itself will call out “dropdown blocked” instead of just failing silently.
📌 Lesson: A Test Can Fail Because of a Banner, Not a Bug
Sometimes it’s not the core flow that breaks — it’s the endless pop-ups layered on top of it.
🧪 Test Garden Tip: Don’t Trust Appearances
- ✅ Use 𝚒𝚜𝙳𝚒𝚜𝚙𝚕𝚊𝚢𝚎𝚍() or visibility checks — but also confirm interactability.
- ✅ Inspect CSS properties like 𝚙𝚘𝚒𝚗𝚝𝚎𝚛-𝚎𝚟𝚎𝚗𝚝𝚜 and 𝚣-𝚒𝚗𝚍𝚎𝚡.
- ✅ In mobile, watch for overlays from modals blocking clicks.
- ✅ Add custom assertions for “click readiness” to fail fast.
💬 Lady’s Log
“Some bugs hide in shadows. Others sit in plain sight, smiling, daring you to click.”
Dropdowns, modals, buttons — they remind us that in automation, looks can deceive.
— 𝓛𝓪𝓭𝔂 𝓓𝓪𝓲𝓼𝔂 𝓑𝓾𝓰 🐞🌼
📚 Petal Picks
- ⬇️ “Intercepted Clicks” — Titus Fortner
- 🎨 “CSS pointer-events: none explained” — MDN Web Docs
- 🛠 Tool: Appium Inspector — to visualize what’s really blocking taps
💌 Coming Up Next
“The Checkbox That Checked Itself”
You uncheck it. Refresh. It’s checked again. Uncheck. Save. Reload. Checked. Was it haunted? A feature? Or a developer’s idea of a prank?
Find out in next week’s bug tale.