Wrong results of highlighting

[pbelzek-cq]

Is there an existing issue for this?

• I have searched the existing issues

Description of the bug

I've observed that Fuse.js highlights substrings of searched keywords. It doesn't make any sense to do so because it leads to false positives and highlights that provide no value for the user.

You can find a sandbox here: https://codesandbox.io/p/sandbox/wc7pl4

(I'm on 7.0.0 version - there is no 7.0.0 option in the select menu in issue creator, you should add it)

The Fuse.js version where this bug is happening.

Other (please specify in description)

Is this a regression?

• This is a regression bug

Which version did this behavior use to work in?

None

Steps To Reproduce

1. In the input field type in olympics
   In matches array, most of the selected indices refer to substrings of the search keyword.For example, it highlights sets of two letters like ic in the word office because ic also exists in the word olympics.

Expected behavior

It should highlight provided keywords as a whole, not a substrings of them. When searching for olympics it should only highlight the word olympics, not ic in the word office.

Screenshots

No response

Additional context

No response

[github-actions]

This issue is stale because it has been open 120 days with no activity. Remove stale label or comment or this will be closed in 30 days

[AngPagibigNgDios]

I'm still figuring this out, Search like Goliath highlighted is okay, but Philistines, and got random letter, or th, la, etc, is too much highligthing that doesn't give value to research of website browser.

[krisk]

Apologies for the long delay on this. I dug into it. The highlight code was marking every character in the text that appears anywhere in the pattern, not just the ones inside the actual matched window. So for olympics, every o, l, y, m, p, i, c, s anywhere the scan visited got marked. That's why ic highlights inside office: both letters happen to be in the olympics alphabet.

Same bug as #505, #611, #691, and #793.

Fix queued for 7.4.0-beta.6: restrict highlights to the actual matched window. For your olympics / olympic medical office repro, the output drops from six entries (with multi-character bleed into "medical" and "office") to two: [0,6] (the olympic match) plus a 1-character residual [8,8]. If you want to drop short residuals like that, set minMatchCharLength: 2.

There's a deeper fix that would remove the residual entirely, but it has perf implications, so for now this should suffice (hopefully).

Reopening to track shipping. Thanks for the clean repro and patience on this one.

[krisk]

Shipped in v7.4.0-beta.6 (npm install fuse.js@beta).

For your olympics / olympic medical office repro the indices output now drops from six entries to two: [0,6] (the real olympic match) and [8,8] (a single-char residual from the algorithm's error-extension). Leaving this open for now in case the [8,8] is worth a deeper fix later. Let me know if it's a problem in practice, or if minMatchCharLength: 2 filters it out enough for your case.

Bonus: the fix is also a perf win. ~15% faster fuzzy search on includeMatches queries, and 2-5% on plain fuzzy search. Removing the inner-loop mask write was a bigger savings than the new post-loop fill costs.

[AngPagibigNgDios]

Apologies for the long delay on this. I dug into it. The highlight code was marking every character in the text that appears anywhere in the pattern, not just the ones inside the actual matched window. So for olympics, every o, l, y, m, p, i, c, s anywhere the scan visited got marked. That's why ic highlights inside office: both letters happen to be in the olympics alphabet.

Same bug as #505, #611, #691, and #793.

Fix queued for 7.4.0-beta.6: restrict highlights to the actual matched window. For your olympics / olympic medical office repro, the output drops from six entries (with multi-character bleed into "medical" and "office") to two: [0,6] (the olympic match) plus a 1-character residual [8,8]. If you want to drop short residuals like that, set minMatchCharLength: 2.

There's a deeper fix that would remove the residual entirely, but it has perf implications, so for now this should suffice (hopefully).

Reopening to track shipping. Thanks for the clean repro and patience on this one.

this helped though in my part, but unfortunately, all other valid two to three words matching the search are no longer highlighted

function highlightMatches(text, indices) {
if (!indices || !indices.length) return text;
const sortedIndices = [...indices].sort((a, b) => a[0] - b[0]);
let result = '';
let lastIndex = 0; sortedIndices.forEach(([start, end]) => {
const matchText = text.slice(start, end + 1);
const beforeChar = start === 0 ? ' ' : text[start - 1];
const afterChar = end === text.length - 1 ? ' ' : text[end + 1];
if (/\W/.test(beforeChar) && /\W/.test(afterChar)) {
result += text.slice(lastIndex, start);
result += <mark>${matchText}</mark>;
lastIndex = end + 1;
}
});
result += text.slice(lastIndex);
return result;
}/* -------------------------------------------------
INIT
-------------------------------------------------- */
document.addEventListener('DOMContentLoaded', () => {
loadBible();
setupSearchBox();
});