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

Steps to reproduce:

Go to https://developer.mozilla.org/en-US/docs/Web/CSS/::before and use find bar to search for "he said, are"

Actual results:

No results found.

Expected results:

Like with Firefox 76 (have currently no 77 to check) the css q::before content should be ignored.

Other Example (https://jsfiddle.net/4n0ojy9s/):
css:
span::after { content: ","; }
html:
1<span></span>234
Should be searchable with "1234".

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

The behavior was changed by Bug 1627643.

Thanks for the reference to Bug 1627643.
With the pref browser.find.anonymous_content.enabled = false the expected result is back.

I'd argue that the expected result is different.

Ideally, I think you should be able to find your 1<span></span>234 text with 1,234. But we don't support that because the range spans an anonymous boundary (the pseudo-element).

So I think restoring the previous behavior in the case that the match would go across an anonymous boundary is better. I can poke.

This restores our previous behavior when matching across anonymous
boundaries, as that's not something we currently can support because DOM
ranges can't represent that.

Backed out changeset f91b6b609218 (bug 1654270) for Mochitest failure in chrome/test_bug451540.xhtml. CLOSED TREE

Log:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=310590726&repo=autoland&lineNumber=9494

Push with failures:
https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&revision=f91b6b609218d74353b708452459604c9841c6a3

Backout:
https://hg.mozilla.org/integration/autoland/rev/49873423415e24d24a4a4af792d64e460ced8ec8

This was kind of a pre-existing bug, though not surfaced because we
didn't have conditionally-appearing text nodes I guess.

If we are doing a match in a non-anonymous subtree, we'd skip the
anonymous text (that's alright). But if we actually reach the end of the
document (as it is the case on the test that starts failing with the
other patch in this bug), we'd just early-return, rather than restarting
where we left off, which is not fine and means that potential matches in
anonymous subtrees that were skipped won't show up.

This fixes the bug... Eventually we should probably come up with a
better structure than this gigantic while (true), probably moving all
these variables into their own struct, but today is not that day :)

Thank you very for working so fast on this.

You are right, searching including the pseudo-element might be a solution, too. But I fear the discussion. There might be more similar cases like following or custom elements:

1<svg style="width:4px;height:13px;vertical-align:bottom"><text y="10">,</text></svg>234<br>
a<img style="vertical-align:bottom" src='data:image/svg+xml;utf8,<svg width="4" height="13" xmlns="http://www.w3.org/2000/svg"><text y="10">,</text></svg>'>bcd<br>
x<q>y</q>z

The first one can be found with "1,23", the second as "abc" and the third with "xyz" (only with browser.find.anonymous_content.enabled=false).

https://hg.mozilla.org/mozilla-central/rev/43c100fa56ed
https://hg.mozilla.org/mozilla-central/rev/aa337bc4d669

(In reply to Axel Sander from comment #9)

You are right, searching including the pseudo-element might be a solution, too. But I fear the discussion. There might be more similar cases like following or custom elements...

Yeah, I'm generally of the opinion that people should find by what they see. Quotes are a good example where we may want to skip quotes regardless of whether they're pseudo-elements or not. Or maybe find-in-page should have an "ignore punctuation" setting, not sure.

But anyhow, for now the behavior you want is restored. In order to find mixed pseudo and non-pseudo content we'd need to also fix stuff like selection across shadow boundaries, for example. Which is something that there's other people working on, but until that's ready... :)