feat(search): include folders as navigable search results - #14
Merged
arpit-bruno merged 10 commits intoJul 30, 2026
Conversation
sundram-bruno
marked this pull request as ready for review
July 28, 2026 20:17
Contributor
|
The search-key removal is done (Fuse matches name+url only ✓), but the breadcrumb is still shown in every result row, and the tests/CSS/fixtures all encode showing it. So the code intends to display breadcrumbs — the PR's "breadcrumbs no longer shown in the search results UI" is stale. Reconcile: if breadcrumbs should stay (the code + tests say yes), fix the PR description; if they should truly go, delete the rendering + its tests. This is the item you asked me to verify. Two e2e tests pass vacuously — search.spec.ts tests "a result name shown whole gets no tooltip" and "a breadcrumb shown whole gets no tooltip". Both assert toHaveCount(0) right after hover(); toHaveCount(0) succeeds on the first poll (count is 0 before the 500ms dwell), so a regression that opens the tooltip for un-clipped text would ship uncaught. Fix: await page.waitForTimeout(900) before the assertion, like the sibling "leaving a breadcrumb before the dwell…" test. Can you please check these edge cases @sundram-bruno |
sundram-bruno
changed the title
Contributor
Author
|
@sachin-bruno handled the comment 2 . first one was already handled. |
sachin-bruno
approved these changes
Jul 29, 2026
sundram-bruno
force-pushed
the
feat/search-folder-results
branch
from
July 29, 2026 13:06
440f1fb to
ffbca1e
Compare
Index folder nodes alongside requests so a folder can be found by name and opened from the palette. Folder rows show a folder glyph, the folder name, its breadcrumb and a recursive request count, and rank above request results. Search now matches on name and url only; the breadcrumb is display-only and is shown on both row types so folders sharing a name across branches stay distinguishable. Long chains are elided and revealed in full on hover.
The tooltip anchor is a plain span inside the row button, so it never takes focus and its bubble is aria-hidden. On an elided chain that left keyboard and screen-reader users with only "Hotels / … / v3", which defeats the breadcrumb's purpose of telling same-named folders apart; the span now carries the full chain as its accessible name. A chain shown whole no longer mounts a tooltip at all, since the bubble would only repeat what is already on screen.
Folder names are free text and may contain " / " themselves, so splitting the joined chain back apart mis-segmented it and elided to the wrong folders. The record now carries ancestorNames and the chain is only ever joined for paint. Also covers requestCountLabel directly, and pins the tooltip's cancel-on-leave path: the folders fixture gains a branch deep enough for a breadcrumb to elide, which is the only case that shows a tooltip at all.
Mounts a collection built to be hostile to the search palette: chains deep enough to elide, folders sharing a name across branches, names long enough to fight the row for width, a folder whose own name contains the breadcrumb separator, and folders counting zero or one request. No automated spec reads it, so hostile cases can be added freely without destabilising the fixtures the e2e suites depend on.
The title row had no min-width and the breadcrumb would not shrink, so the row's minimum width was the whole chain. That pushed the body wider than the panel: the name collapsed to an ellipsis, the results list scrolled sideways, and the row's hover background stopped at the container edge because the button is only ever as wide as its container. The name now takes the width it needs and the chain yields, capped at 45% and ellipsised, with the list refusing horizontal overflow outright. A chain can now be cut by width as well as by depth, and a CSS ellipsis leaves no marker in the text, so the tooltip trigger is measured on the laid-out node instead of inferred from the segment count. The name gets the same treatment, since a clipped name is otherwise unreadable.
Growing the name filled the row with blank space beside short names, pushing the chain to the far edge away from the name it qualifies, and the 45% cap then cut the chain regardless of how much room was actually going spare. Neither part grows now, so the chain sits beside the name, and the chain carries a far higher shrink factor so it is what yields under pressure. The name only truncates once the chain has given up its width, and the arbitrary cap is gone.
The name span had no test id, so the overflow spec reached for its class, against the page-object rule that parts are found by role or test id. It has one now, along with a page-object locator for its tooltip. The name tooltip shipped with no coverage at all: two cases now pin it, a narrow viewport where the name cannot fit and a wide one where it can. TOOLTIP_DELAY_MS loses its BREADCRUMB_ prefix, since the name tooltip reads it too.
Both "shown whole gets no tooltip" cases asserted a count of zero immediately after hovering. The tooltip waits 500ms before opening, so the assertion was satisfied on its first poll by the bubble simply not having appeared yet, and would have kept passing had the trigger regressed to always-open. Verified by stubbing the clip check to always return true: the old form still passed, the waiting form fails.
…nfig Trailing commas and double-quoted strings, autofixed. The branch was written against the old per-package eslint config and predates the root one, which adds @Stylistic and lints only the lines a PR changes.
sundram-bruno
force-pushed
the
feat/search-folder-results
branch
from
July 29, 2026 13:12
ffbca1e to
eff6232
Compare
Defaulting a null box to zero let the width comparison pass while the breadcrumb was rendered but unpainted: 343 > 0 holds whether or not the chain is visible. A display:none regression shipped green. Both boxes are now null-checked first, matching the other bounding-box reads in this file, and a failure names which box was missing instead of reporting 0 not greater than 0.
sachin-bruno
approved these changes
Jul 29, 2026
arpit-bruno
approved these changes
Jul 30, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Docs search indexed requests only. Folders never appeared as results. They existed in search purely as a filter chip and as the breadcrumb line under a matched request. Searching a folder by name returned nothing, and there was no way to reach a folder page from search, even though those pages exist and are routable.
JIRA : BRU-3949
Behaviour
Folders are results
Folders rank above requests
What gets matched
Breadcrumbs
billing/customers/authvsproducts/users/auth) can be told apart.first / … / last.Filters