Layout and design improvements for the manual test runner UI

[psmyrek]

🚀 Summary

Improved the manual test runner UI to make tests faster and easier to find.

It is now possible to save frequently used tests as favorites. Search results show the best matching packages first. Matching package and test names are highlighted. The clear button now looks the same across browsers.

---

📌 Related issues

• Closes https://github.com/ckeditor/ckeditor5-internal/issues/4311.

---

💡 Additional information

The following things have been added or improved:

• Favorites

  Tests can now be added to or removed from favorites. Favorites are saved in local storage. A Favorites section appears at the top of the catalog only when search is empty.

  

• Search

  Search results are ordered by relevance:

  • Exact package names appear first.
  • Package name prefixes and partial matches appear next.
  • Matches found only in test names appear last.
  • Packages with more matching tests are ranked higher.

  Matching text is highlighted in package and test names. Highlighting uses the native CSS Custom Highlight API.

  The native search clear button looked different across browsers and did not appear in Firefox. The runner UI now uses its own clear button. It has the same appearance and behavior in every browser.

  

Other notes:

• Lightning CSS bump

  lightningcss was updated from 1.32.0 to 1.33.0. The previous version did not recognize the CSS Custom Highlight API and printed this warning:

  [vite:css][lightningcss] 'highlight' is not recognized as a valid pseudo-element. Did you mean ':highlight' (pseudo-class) or is this a typo?
  41 |  }
  42 |
  43 |  ::highlight(ckeditor5-manual-search-match) {
     |              ^
  44 |    background-color: var(--search-match-background);
  45 |    color: var(--search-match-text);
  

  Please note that this warning is still printed when running manual tests, because latest Vite still uses the older 1.32.0 version.

  • Latest stable: Vite 8.1.5 with lightningcss: ^1.32.0.
  • Beta: Vite 8.2.0-beta.0 with lightningcss: ^1.33.0. Published on 22.07.2026 (one day ago).

  The current warning from Lightning CSS is non-fatal:

  • The build succeeds.
  • Lightning CSS 1.32.0 retains the ::highlight() rule.
  • Search highlighting works in the browser.

  So, the warning will gone either when we will be able to bump Vite, or if we add the override in the commercial's workspace.

• Fuzzy search

  I decided not to add fuzzy search in this PR. Highlighting uses the native CSS Custom Highlight API and relies on locating the exact query text in package and test names. A fuzzy result may not contain that text (for example tabel matching table), so it could not be highlighted consistently. Supporting fuzzy search properly would require additional logic and a more complex highlighting implementation, which is outside the intended lightweight scope of this PR. The current exact substring search with relevance-based ordering remains predictable and fully highlighted.

[pomek]

Is there any chance to add the star icon (and related actions) to the top bar?

This would simplify modifying the favorite tests list directly from a demo, instead of looking for it on the splash screen.

[psmyrek]

Added the favorite button to the top bar:

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 3 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 510dde5. Configure here.}

[filipsobol]

1. Triple feature detection in updateSearchHighlights(). This is the one clear LLM-ism on the branch:

   if ( typeof CSS == 'undefined' || !( 'highlights' in CSS ) ) {
         return;
   }
   // ...
   if ( !normalizedQuery || typeof Highlight == 'undefined' ) {
         return;
   }

   • typeof CSS == 'undefined' is always false — the CSS global has existed in every browser for over a decade, and this code only runs in a browser.
   • typeof Highlight == 'undefined' is dead too: any browser that exposes CSS.highlights also exposes the Highlight constructor; they shipped as one API.
   • 'highlights' in CSS is the only defensible check (Firefox gained the API relatively recently), and even that is arguable for an internal dev tool targeting evergreen browsers.

   Suggestion: reduce to at most the single 'highlights' in CSS guard.

2. textNode.textContent || ''. The line above already verifies nodeType == Node.TEXT_NODE, and a text node's textContent is never null. The || '' exists only to appease TypeScript's string | null type — harmless, but a ! assertion would be more honest about intent. Cosmetic.

3. Redundant loop condition in findMatchOffsets(). while ( start < normalizedText.length ) guards nothing: the indexOf returning -1 is what actually terminates the loop (empty query is already rejected, so start strictly increases). Harmless, but the condition implies a protection that isn't doing anything.

[psmyrek]

Thanks for the review - all requests addressed in 1e0a816.