2.0 KiB
| title | status | type | priority | created_at | updated_at |
|---|---|---|---|---|---|
| bit-by-bit: [hidden] attribute defeated by CSS display rules — celebration overlay stuck onscreen | completed | bug | normal | 2026-07-14T04:30:04Z | 2026-07-14T04:32:45Z |
User report: after onboarding, a bare "You did it!" celebration modal covers the app and its buttons appear dead.
Root cause: .celebration-overlay, .onboarding-overlay set display:flex (and #artworkActive has inline display:flex, .upload-preview sets display:flex). Author CSS beats the UA stylesheet's [hidden]{display:none}, so toggling the hidden attribute in JS has no visual effect on these elements. The celebration overlay was therefore visible from page load with placeholder text, and hideCelebration() couldn't hide it. jsdom tests missed it (no layout).
Fix: global [hidden]{ display:none !important; } rule (also covers the inline-style case on #artworkActive).
- Apply global [hidden] rule
- Verify in a real headless browser: celebration hidden on load, onboarding visible on first run, hides after finishing
Summary of Changes
Added [hidden]{ display:none !important; } to the base styles in bit-by-bit/index.html (with a comment explaining why). This makes the hidden attribute authoritative over author display rules (.celebration-overlay/.onboarding-overlay flex, #artworkActive inline flex, .upload-preview flex).
Verified with headless Firefox screenshots (fresh profile each):
- Fresh load: onboarding wizard visible, no stray celebration modal.
- Seeded mid-progress state: main app renders, 3/4 pixels · 75%, overlays hidden.
- Final check-off: image completes to 4/4 · 100%, canvas keeps showing the finished art via the pendingCelebration snapshot, gallery count increments — confirming the celebration flow renders correctly in a real browser.
Lesson recorded: jsdom flow tests check the hidden property, not computed style — visibility bugs need a real-layout browser check.