Fix case-sensitive path matching for the search box

[LeonardYam]

Description

Currently, navigating to a file-path with uppercase characters like /encoding/encodeInto.any.html does not work.
Somewhat related issue: #3009

Review Information

Enter any file-path which contains upper-case characters into the search-box.

Local build vs production:

2023-04-06.19-48-58.mp4

Changes

matches = matches
          .filter(p => p.toLowerCase())
          .filter(p => p.includes(query))

Auto-complete options are generated from matches. I believe the intention here was to map all paths to a lower-case string and perform query matching. However, converting all paths to lowercase would cause further issues later (since the file-path is case-sensitive). Thus, the change was to perform case-insensitive query matching while keeping case-sensitive paths.

if (autocompleteSelection.value === path) {
  this.dispatchEvent(new CustomEvent('autocomplete', {
    detail: {path: path},
  }));

path refers to queryInput which is the text within the search-box. Currently, queryInput is being converted to lowercase and hence the equality-check fails for any path which contains uppercase characters. The path passed into detail should also be changed to use the case-sensitive value in autocompleteSelection.

Notes

I am unable to test whether these changes affects complex queries due to #2941. This would also mean that fixes on #2980 and other bugs would be unable to proceed.

An alternative solution to this would be to ensure queryInput does not get lowercased, however due to the above issue, keeping it lowercase for now would be the safer option.

[DanielRyanSmith]

I was having trouble replicating this issue, but then I noticed you're using Firefox as your browser to test the site. This seems to be a Firefox-specific problem, as it doesn't trigger the handleChange() method after selecting from the search box options (which I assume you trigger instead in the video by clicking out of the search box). This problem is caused because the query is changed to lowercase in the search box before handleChange() is called.

This PR in its current form breaks the implementation on Chrome and Safari, but after playing around, the suggested changes below should work on all browsers.

I've submitted some changes that break other browsers' view on this site before, so I have some experience. This is a good reminder to test site changes on each of the major browsers, and a reason why the Interop effort is so important. 🙂

Thanks for identifying a problem and bringing forward a solution @LeonardYam!

[LeonardYam]

Ah, thanks for pointing it out, I'll remember to test on Chrome and Safari in the future!

I have committed the relevant changes and this should be ready for merging.

Note:
Will #2941 be resolved anytime soon? I would be willing to pick it up since working on bugs related to search queries requires this to be fixed first.

[DanielRyanSmith]

Thanks again!

[DanielRyanSmith]

About #2941, I do not think that this will be resolved any time soon, but there are ways to run the search cache locally, although it is intensive in terms of processing power. The instructions for that are in a readme file in a searchcache subfolder