Quick-search: Enter never opens a tile (TypeError on numeric placement id), and every tile is dimmed including matches

[rubenvdlinde]

Summary

WorkspaceApp.vue::activateSearchResult() throws a TypeError on every invocation, so pressing Enter on a quick-search match never opens the tile (tile-quick-search REQ-QSEARCH-003, "Enter opens the selected tile").

A second, closely related defect in applySearchDimming() means the de-emphasis is applied to every tile including the matches.

Both have the same root cause: placement ids are numbers, and both functions treat them as strings.

Found during hydra gate-19 round 2 (#92). Measured in CI, then isolated statically.

Defect 1 — Enter never activates (crash)

src/views/WorkspaceApp.vue:

activateSearchResult(item) {
    const placementId = item?.placement?.id
    if (!placementId || !this.$el) { return }
    const el = this.$el.querySelector(
        `.launchpad-grid-item[data-placement-id="${placementId.replace(/"/g, '\\"')}"]`,
    )

item.placement.id is the WidgetPlacement entity id — an integer through jsonSerialize(). Number.prototype.replace does not exist, so placementId.replace(...) raises TypeError: placementId.replace is not a function. The guard above it does not catch this: a non-zero integer is truthy, so execution reaches the crash.

The exception is thrown inside a Vue event handler, so nothing surfaces to the user — Enter simply does nothing.

How it was isolated

The e2e test at tests/e2e/tile-quick-search.spec.ts pressed Enter on a single match and recorded clicks with a capture-phase listener. It failed with an empty activation list. Two splitting probes were added and both passed in CI run 31483882342:

• the rendered cells do carry a[href] (so activateSearchResult()'s fallback-to-focus() branch is not the explanation);
• the search input does still hold focus when Enter is pressed.

The sibling test proving aria-activedescendant selection tracking passes, so the selection mechanism is sound. Anchor present, focus correct, selection correct, no click — which the TypeError explains exactly.

Defect 2 — every tile is dimmed, including the matches

Same file:

const id = el.getAttribute('data-placement-id')   // ALWAYS a string
el.classList.toggle('launchpad-grid-item--dimmed', matchIds.includes(id) === false)

matchIds comes from the search results, i.e. the same numeric placement ids. Array.prototype.includes is strict-equality, so [12, 13].includes('12') is false — no tile ever matches, and the class is applied to all of them.

REQ-QSEARCH-002 requires non-matching tiles to be de-emphasised; applying it to matches as well defeats the feature.

A note on the test that did not catch Defect 2

tests/e2e/tile-quick-search.spec.ts currently asserts dimmed count > 0 after typing. That is satisfied by "everything is dimmed", so it passes on the buggy behaviour. It should assert that the tiles matching the query are NOT dimmed while the others are. That tightening is deliberately not applied in #92, because on current development it would be red — it belongs with the fix.

Suggested fix

Coerce once, at the boundary, in both functions:

const placementId = String(item?.placement?.id ?? '')
if (placementId === '' || !this.$el) { return }

const matchSet = new Set((matchIds ?? []).map(String))
…
el.classList.toggle('launchpad-grid-item--dimmed', matchSet.has(id) === false)

Coverage status

tile-quick-search::enter-opens-the-selected-tile is left as an open gate-19 finding — not annotated with @e2e exclude — because the scenario is browser-observable and the reason it has no passing test is that the product is broken. The other 8 scenarios in REQ-QSEARCH-001..003 have real, passing tests on #92.

[rubenvdlinde]

Fixed in e24334b6 (PR #99), on development.

Both defects had one root cause: a WidgetPlacement id is an integer and a DOM attribute is a string.

• activateSearchResult() called .replace() on the id. Number.prototype.replace does not exist, so every activation threw a TypeError inside a Vue event handler — where nothing surfaces it — and Enter silently did nothing. Now String(item?.placement?.id ?? ''); the ?? '' is deliberate so a null id becomes the empty string and is rejected by the guard, rather than being stringified into "null" and sent to querySelector as a real id to look for.
• applySearchDimming() compared getAttribute('data-placement-id') against the raw ids with Array.includes, which uses SameValueZero and does not coerce — [7].includes('7') is false, so every tile dimmed on every query, including the matches. Both sides are now normalised to strings.

Why the unit suite stayed green: all five existing fixtures in WorkspaceApp.spec.js seeded the placement id as a string ('p1', 'match'), a type the API never sends. Re-running the same assertions with integer ids against the unfixed source failed twice, one of them with TypeError: placementId.replace is not a function verbatim. Three integer-id regression tests are added, and they were run red against the unfixed source and restored byte-identically before landing.

The disclosed assertion landed with the fix, as promised. The filtering test's dimmed > 0 was satisfied by "every tile is dimmed" — it was passing for the wrong reason, and was recorded as such rather than quietly tightened, because tightening it before the fix would simply have been red. It is now per-element and by identity: the non-matching tile must carry the class and the matching one must not, with the aggregate count kept as a control so a refactor that stops applying the class at all cannot pass.

tile-quick-search::enter-opens-the-selected-tile now has a real e2e test rather than an @e2e exclude. It records the anchor's href from a capture-phase click listener with preventDefault, because the seeded links point at example.invalid and a real navigation would fail for a network reason instead of a product one. The two splitting probes from the investigation are kept, so a regression names its own cause.

Verified: 13/13 Playwright and 26/26 vitest locally, and the full Code Quality run on #99 was 24 pass / 0 fail — including E2E Tests (Playwright).

gate-19: 143 → 142 from this scenario alone.