demo · v141

Find-in-Page Reveal

Hit Ctrl+F (or use the box below) and search for a word buried inside a collapsed <details> or a hidden=until-found region. Chrome 141 fixes a bug in the revealing algorithm that could infinite-loop or hang on certain nested combinations — now the browser opens the right ancestor chain reliably.

Heads up Requires Chrome 141+. The bug only manifested on specific nestings, but when it hit it could freeze a tab. The fix is invisible by design — successful Ctrl+F navigation is what you should see now.
checking support…
find:
Recipe section (collapsed)

Each item is its own details element; the find-in-page algorithm has to open the right combo, not all of them.

Recipe 1 — soup

A simple onion soup. Cardamom optional.

Recipe 2 — salad

Pickled artichoke heart, shaved fennel, lemon.

Recipe 2a — dressing

Olive oil, white wine vinegar, mustard.

Bestiary section (also collapsed)

Inside, a hidden=until-found region with rare creatures.

try Ctrl+F (or use the find box) and search for artichoke, kraken, or zenith. Chrome 141+ opens the exact ancestor needed.

the algorithm

// Spec change (whatwg/html#11457)
// On find-in-page hit inside a hidden=until-found region OR a closed <details>:
//   1. walk ancestors
//   2. for each closed details, set open=""
//   3. for each [hidden=until-found], remove the hidden attribute
//   4. fire beforematch / scrollIntoView
// Previously: certain shadow / slot interactions caused the walk to loop.
// 141 caps the walk and exits cleanly.

why this angle

Both hidden=until-found and <details> exist specifically to keep large pages performant (long FAQs, recipe collections, docs) while remaining searchable. If find-in-page can't reliably open them, the whole proposition collapses — users see "no match" even though the text is in the DOM. The fix is small, the impact is "the platform's quietly important feature now actually works in edge cases."

see also