1769413 - Find in page missing matches at the beginning of the line

Status: VERIFIED FIXED

(Core :: Find Backend, defect, P3)

Description

[[:sc]]

Steps to reproduce:

Search in page (ctrl+f) with "whole words" active.
It fails when the first character to be found is a hyphen.

(Quite an annoyance because of missing results in places like ffmpeg's documentation site)

Actual results:

The text was only found in places that wasn't a start position.

(Confirmed with inspect element that adding a space in front would make it work)

Expected results:

Find as in the rest of places.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Toolkit::Find Toolbar' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

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

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

For more information, please visit auto_nag documentation.

Comment 3

[[:sc]]

Hopefully normal priority at least? It's like not being able to use whole words.

Comment 4

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1769413 - Treat start/end-of-text as a word boundary for the Find-in-Page whole-words option, even when the adjacent character is punctuation. r=TYLin

Comment 5

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1769413 - Add simple tests for the entireWord option of find-in-page. r=TYLin

Before the patch here, four of the newly-added asserts fail because we don't recognize
a word boundary at the start or end of the block.

Depends on D150247

Comment 6

[Jonathan Kew [:jfkthame]]

This affects punctuation characters in general, not just hyphen; so if the text begins with, say, a quoted word, it's impossible to find that word including its quote marks with Whole Words enabled, although this works if it's not at the start of the text.

A similar issue applies at end-of-text, too. So for example, on the page https://www.mozilla.org/en-US/privacy/, enabling Whole Words and searching for "personal information" correctly finds the quoted phrase in the first paragraph of text, but searching for "personal information?" fails to find the phrase at the end of the heading.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9561e87d41a6
Treat start/end-of-text as a word boundary for the Find-in-Page whole-words option, even when the adjacent character is punctuation. r=TYLin
https://hg.mozilla.org/integration/autoland/rev/2f6bb061b108
Add simple tests for the entireWord option of find-in-page. r=TYLin

Comment 8

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/9561e87d41a6
https://hg.mozilla.org/mozilla-central/rev/2f6bb061b108

Comment 9

[Ardelean Oana, Desktop QA [:oardelean]]

I managed to reproduce this issue on a 2022-05-15 Nightly build on Windows 10 64-bits. Verified as fixed on Firefox 103.0b7(build ID: 20220710185935) and Nightly 104.0a1(build ID: 20220711094852) on Windows 10 64-bits, Ubuntu 22.04, macOS 12.

Comment 10

[[:sc]]

Thanks for the work.
And although it it is working much better I found some cases that still don't work:
For example "-m" was not found when the internal html was this: <samp>minrate (<em>-m</em>)</samp>

Comment 11

[[:sc]]

Sorry, I'm going to try to request information (I guess I could have done this with my previous comment, but I'm not used to reporting bugs here.)
Because of what I explained in the previous comment I don't think the bug should have the resolution of fixed.
I don't know how you're used to manage these cases, should I open a new bug report?

Comment 12

[Emilio Cobos Álvarez (:emilio)]

A new bug report would be best, IMO.

Comment 13

[Emilio Cobos Álvarez (:emilio)]

(Though I think it's ~expected, since we don't treat punctuation as word-start characters).

Comment 14

[Jonathan Kew [:jfkthame]]

(In reply to [:sc] from comment #10)

Thanks for the work.
And although it it is working much better I found some cases that still don't work:
For example "-m" was not found when the internal html was this: <samp>minrate (<em>-m</em>)</samp>

In this case, a whole-word search for "(-m)" should work, but I don't think we treat the boundary between two punctuation characters (the open-paren and the hyphen) as a word boundary, so that's why "-m" won't be found.

Maybe some further adjustment would be useful, though in general it's hard to know what people would expect "whole words" to do in the context of strings of punctuation. The specific problem originally reported here -- which was a more clear-cut case, I think -- is fixed; as Emilio says, it would be best to consider any followup issues in a new bug. Thanks!

Comment 15

[[:sc]]

Looks like this can stay like it is.
I've submitted the second part at https://bugzilla.mozilla.org/show_bug.cgi?id=1782231
Thanks again.