Summary
When using cmd+f to search a block whose output is still streaming (for example, logs from a long-running server), the currently selected match jumps to a different piece of text as new matches are appended, instead of staying anchored to the originally selected match.
Problem
The find UI appears to identify the "currently selected" match by its index in an ordered list of matches rather than by a stable handle to the actual matched span. When new matches arrive earlier in the list (or the list is rebuilt to include the new output), the selection stays at the same numeric index (e.g. still "5 of N") and the highlighted text visibly changes, even though the user's selection should have shifted to a higher index to remain on the same text.
This makes find effectively unusable for inspecting a specific occurrence of a string in a block whose output is still being appended: the user keeps losing the location they navigated to whenever new matches arrive.
Expected behavior
While the match list grows due to new live output, the selection should remain anchored to the same underlying matched text. If new matches appear before the current one, the index should update accordingly (e.g. "5 of 100" becomes "6 of 101"), but the highlighted text should not change.
Actual behavior
The selection stays at the same numeric index as new matches stream in (e.g. "5 of 100" → "5 of 101") and visually jumps to whatever match now occupies that position. The text the user had navigated to is no longer highlighted, and they have to re-find it manually.
Reproduction steps or desired workflow
- Run a long-running command in a Warp block whose stdout/stderr produces lines containing some search term (for example, a server that periodically logs the word
request).
- While output is still streaming, press cmd+f and search for that term.
- Use the find navigation to step to a specific match (e.g. result 5 of 100) and note which line is highlighted.
- Wait for new output containing additional occurrences of the search term to be appended.
- Observe that the highlighted match changes to a different line while the counter stays at "5 of N+k". The originally selected text is no longer the selected match.
Artifacts
None attached
Warp version
Unknown
Operating system
macOS
Summary
When using cmd+f to search a block whose output is still streaming (for example, logs from a long-running server), the currently selected match jumps to a different piece of text as new matches are appended, instead of staying anchored to the originally selected match.
Problem
The find UI appears to identify the "currently selected" match by its index in an ordered list of matches rather than by a stable handle to the actual matched span. When new matches arrive earlier in the list (or the list is rebuilt to include the new output), the selection stays at the same numeric index (e.g. still "5 of N") and the highlighted text visibly changes, even though the user's selection should have shifted to a higher index to remain on the same text.
This makes find effectively unusable for inspecting a specific occurrence of a string in a block whose output is still being appended: the user keeps losing the location they navigated to whenever new matches arrive.
Expected behavior
While the match list grows due to new live output, the selection should remain anchored to the same underlying matched text. If new matches appear before the current one, the index should update accordingly (e.g. "5 of 100" becomes "6 of 101"), but the highlighted text should not change.
Actual behavior
The selection stays at the same numeric index as new matches stream in (e.g. "5 of 100" → "5 of 101") and visually jumps to whatever match now occupies that position. The text the user had navigated to is no longer highlighted, and they have to re-find it manually.
Reproduction steps or desired workflow
request).Artifacts
None attached
Warp version
Unknown
Operating system
macOS