In-page find can fail under virtualisation

What it is

System find matches text that is already painted. A virtualised list unmounts rows outside the window, so those rows’ strings are not in the document, and find reports absence even when the data hold them. That is the find-versus-window crack: people think they are searching the whole list; the system is searching this screen. It differs from collapsed content — collapse at least leaves nodes in the tree; virtualisation never created the nodes.

Why it happens

Find assumes “text on the visible page ≈ text in the document tree.” Virtualisation breaks that approximation on purpose: for performance, the tree covers the window only. Matches are therefore clipped by the window; distant hits never enter the count and are never scrolled to. An in-app search box that still scans only visible nodes copies the same crack under a different door. To close it, find must walk the data: match in the full array, jump the window to that row, create the node, then attach a highlight. Reporting “found” without moving the window still leaves the user seeing nothing. Counts must also come from the data layer, or “1 / 1” means “1 / 1 of this screen.”

Studying it

Bury a word that occurs only on a distant row of a long virtualised list, and locate it with system find and with in-app find. Independent variables: whether find queries the data layer, whether a hit jumps the window. Dependent variables: reported found, actually seeing a highlight, false “no results.” System find on an unpatched virtualised list should systematically miss the distant word.

Where it stops holding

If the app blocks system find, offers its own, and states that it searches all data, the crack can be patched. Print and export that walk the data layer are not limited by the window, but they are not find. Assistive “find in page” likewise sees only nodes in the tree, and needs the same data-layer path, with focus placed on the newly created row after the jump. A short window buffer will not save find — the buffer is still far smaller than the collection.

Applying it

• Give a virtualised list a data-layer find; on a hit, move the window, render the row, then highlight.
• Do not let system find on an unpatched virtualised list pretend to search everything; if you cannot patch it, say on no-result that only visible rows were searched.
• Count hits against the full set, not the window.
• How to check: search a word that exists only on screen N. The row must appear highlighted. “Found” with nothing visible, or “no results,” means the crack is still there.

Related

• Within the group: E4.18.1 Virtualized lists render only what is on screen so long lists stay usable · E4.18.3 The scrollbar’s position must map honestly to the real amount of data · E4.18.4 Placeholder flicker during a fast flick hurts readability
• Adjacent: E4.07 Accordions · E2.10 Search fields
• Search terms: find in page · virtualized search · unmounted nodes