1645990 - find whole word does not find a word

Status: VERIFIED FIXED

(Core :: Find Backend, defect)

Description

[raypapworth]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0

Steps to reproduce:

search for "con" as whole word in this page
https://www.compart.com/en/unicode/search?q=con#characters

Actual results:

does not find con in the phrase "Latin Capital Letter Con" which exists on the page

Expected results:

should have found this word and some others

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:mikedeboer, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:enndeakin, since the bug doesn't have a severity set, could you please set the severity or close the bug?

For more information, please visit auto_nag documentation.

Comment 4

[Kesara Rathnayake]

Same issue in https://datatracker.ietf.org/meeting/115/agenda
Searching for "art" with Whole Words checked doesn't give any results because firefox treats text in <span> and text after that as a single word if there's no space in between.

Example:

<span class="badge">art</span><a class="discreet" href="/group/core/about/">core</a>

Searching for "art" with Whole Words doesn't give any matches while
Searching for "artcore" with Whole Words does.

Reference: https://github.com/ietf-tools/datatracker/issues/4751

Comment 5

[Jonathan Kew [:jfkthame]]

(In reply to Kesara Rathnayake from comment #4)

Same issue in https://datatracker.ietf.org/meeting/115/agenda
Searching for "art" with Whole Words checked doesn't give any results because firefox treats text in <span> and text after that as a single word if there's no space in between.

Example:

<span class="badge">art</span><a class="discreet" href="/group/core/about/">core</a>

Searching for "art" with Whole Words doesn't give any matches while
Searching for "artcore" with Whole Words does.

Reference: https://github.com/ietf-tools/datatracker/issues/4751

The question of whether a <span> (or other inline element) boundary should be treated as a word boundary is a tricky one, and I don't think there's a simple, always-correct answer. Probably a reasonable heuristic would be that if there's a non-zero margin/border/padding present, that is regarded as a word boundary; but implementing that in the Find code may be tricky.

The original report here in comment 0 is a bit different, in that the content is presented in a table, and the "problem" is that Find is looking beyond the table cell to the next row and seeing more text, with no intervening space. I think it'd make sense to treat table rows like separate blocks for search purposes; we don't let "find" match across block boundaries, and we should treat table rows (and headers/footers) similarly.

That would fix the original case reported here, though it will not resolve the inline version of such issues, which are less clear-cut IMO.

Comment 6

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1645990 - Treat table rows as separate blocks for Find-in-page purposes, rather than matching continuously across row boundaries. r=emilio

Comment 7

[Jonathan Kew [:jfkthame]]

One other note, just for the record: the Find code does already treat <td> elements as separate blocks, so the issue here wouldn't have arisen if the page were constructed with actual table-cell elements. But the page in question actually just uses <div> elements everywhere, and sets display: table-row, display: table-cell, etc., on them to create the table layout. So then we don't see them as separate blocks. The patch above addresses this by checking for table-element display properties.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b20f8573afca
Treat table rows as separate blocks for Find-in-page purposes, rather than matching continuously across row boundaries. r=emilio

Comment 9

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/b20f8573afca

Comment 10

[Ardelean Oana, Desktop QA [:oardelean]]

Reproducible on a 2022-12-13 Nightly build on macOS 12 using the STR from Comment 0.
Verified as fixed on Firefox 110.0b2(build ID: 20230117185909) and Nightly 111.0a1(build ID: 20230118095131) on macOS 12, Windows 10, Ubuntu 22.