User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36

Steps to reproduce:

Open the attachment and search for 東京 on the page.

Actual results:

The search will fail to locate the word 東京 that has ruby annotations.

Expected results:

Find-in-page should find text that has ruby annotations.

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

There's some more detail, and links to a couple of tests, at https://w3c.github.io/jlreq/gap-analysis/#issue255_inline_notes

It would have worked better if the content is like <ruby><rb>東<rb>京<rt>とう<rt>きょう</ruby> instead.

There are several possible behaviors we may want, from easy to hard:

The easiest one is to completely ignore any ruby annotation in search, which can probably be done via simply skipping all the nodes with display: ruby-text and display: ruby-text-container in SkipNode. The behavior can probably even be pref'ed in case anyone wants a different behavior. The downside is that the annotations would not be searchable, which may or may not be good.

The next easy one might be to treat all ruby texts and ruby text containers as blocks, and create a new concept like an "atomic" content which includes it, so that the content in them will be searchable, but wouldn't be mixed with anything on the base text. But it seems to me that the current find implementation can't even search across an out-of-flow block, so the behavior would probably be very undesirable unless we can also fix bug 1116904.

A variant of the above is, in addition to make ruby texts individual atomics, we group continuous ruby text boxes together so that we make text in a ruby text container findable together. This wouldn't help the example in either this bug or bug 1746083, as they all use separate ruby text anyway, given that we are the only browser that supports continuous ruby text, so it probably doesn't make much sense to pursue.

The ultimate thing would be allowing finding ruby base and their corresponding ruby text interchangeable, i.e. <ruby><rb>東<rb>京<rt>とう<rt>きょう</ruby> may be searched via either 東京, とうきょう, 東きょう and とう京. It would probably be the most useful behavior in all cases, but will require non-trivial rewrite of the find algorithm. If such a rewrite ever happens, this may be one thing to be taken into consideration. This alternative searchable content might be useful for other cases like <abbr>.

Given these, I think the most sensible thing to do here is probably to do the easiest one, so that at least we make the behavior more useful in common cases.

https://hg.mozilla.org/mozilla-central/rev/5659a639a122

I was able to reproduce the issue on Win10 using build 88.0a1 (20210318213531), I received only one search result instead of 2.
Verified as fixed on Win10/Mac10.13/Ubuntu20.4 using builds 98.0b2(20220208185809) and 99.0a1(20220210065747). (I got 2 search results).

Thanks for fixing it.

I tried this in Firefox 98. Although the ruby-annotated text can be searched, only half of the ruby annotation is highlighted. IMO the ruby annotation should not be highlighted. Even if they should, they should all be highlighted together.

Behavior in Firefox 98