User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:79.0) Gecko/20100101 Firefox/79.0

Steps to reproduce:

The "Search in page" (Ctrl+F) sometimes find more than expected results, they are duplcated.

1. Open this page: https://naruto.fandom.com/fr/wiki/Ry%C3%BBgan?action=edit
2. Search in page any word, example "Ryûgan".
3. 19 "Ryûgan" results must be found, but 37 are actually found

Actual results:

More results than expected are found, seems like hidden elements in page are taker in account.

Expected results:

Only visible results must be counted and be browsed with Previous/Next (Shift+F3 / F3).

Firefox will match css generated text like element::before {content:'Ryûgan';}
But, Chrome would not.

Triggered by: 1299909504c95261d946df29a97e57ec8df4e36e Emilio Cobos Álvarez — Bug 1627643 - Allow to find and display selection native anonymous content. r=jfkthame

That was an intentional change. But I still only see 19 matches in that page.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #2)

That was an intentional change. But I still only see 19 matches in that page.

STR:

1. Open this page: https://naruto.fandom.com/fr/wiki/Ry%C3%BBgan?action=edit
2. Click "Source" tab of toolbar of editor
3. Ctrl+F , Find in page with "Ryûgan".

Actual Results:
19 "Ryûgan" results must be found, but 37 are actually found

Ahh, indeed I see what they're doing. They are overlaying the text using pseudo-elements, with color: transparent.

I wonder if we should add color: transparent to the list of things that don't match find-in-page... Though I suspect somebody would use text-shadow or something to display the text...

The page could instead of using pseudo-elements, use <span style="visibility: hidden"> or such.

Hmm, so pdf.js uses color: transparent text to support selection and find-in-page, so that's not really going to fly :(

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

For more information, please visit auto_nag documentation.

For your information, all wiki projects on Fandom (Naruto Wiki being one of them) will be eventually migrated on the new platform, called UCP, running on a new MediaWiki software. If things turn out well, all migrations should be completed in the coming months. Some projects have already been created/migrated on the new platform as well, but the same issue can be seen. As an example, on this page https://wreckit-woodhouse.fandom.com/wiki/Comment_as_reply_forum%3F?veaction=editsource (only in Source Editor), when we try to find the word "Problem", that fits well for this situation, there is only 3 occurrences, but Firefox finds 6.

Due to the fact the old plateform will be shut down in a couple of month, maybe you should focus effort in the source editor of the new plateform, without forgetting the method used for syntax highlighting on the legacy plateform can be used elsewhere too.

Interesting, that's basically the same problem (color: transparent text getting found in find-in-page). But I can repro the same issue (6 matches instead of 3) in Chrome, right?

The issue is that the page is overlaying transparent text on top of non-transparent text and find-in-page still matches it. As I said, I think the cleanest solution in this case would be to stop matching transparent text for find-in-page, but that breaks pdf.js which uses this trick exactly to get text-selection and find-in-page functionality...

So those approaches cause badness, but I tend to thing that the current behavior (over-reporting rather than under-reporting) is better, if confusing.

I do not (and don't want to) use Chrome, so I believe you.

The counter is not the main issue, what is causing troubles is the fact that when we browse every matches, invisible matches are browsed too, and when you find 50+ matches (so a total of 100+), sometimes it can very bother people to browse this kind of invisible elements.

If there isn't any solution to bypass this behavior for non-PDF pages, it's too bad, but it's ok.

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Redirect a needinfo that is pending on an inactive user to the triage owner.
:jfkthame, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

I'm inclined to think that we should not be complicating the platform by trying to implement special heuristics to skip "invisible" matches like this.

Transparent text is still text in the document, and a legitimate target for Find-in-Page. It might be significant to the user in all sorts of ways (perhaps it's visible through some other means, like a stroke or text-shadow or background-clip; or perhaps the user will Select All and copy/paste it; perhaps the color changes dynamically, so it's only transiently transparent; maybe the user's screen reader will read the text despite it being transparent; etc).

And this is far from the only mechanism by which content might be invisible to the user, and yet still show up as a Find-in-Page result. How about text with font-size:0; should Find skip that? How about an element with position: absolute; left: -10000px?

--> WONTFIX, as I don't think it's the browser's job to determine that certain parts of the content should be excluded from Find.