Bugzilla

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`](https://searchfox.org/mozilla-central/rev/36a9249dc8543530eeab89df88f37dbab039f9d0/toolkit/components/find/nsFind.cpp#162-167). 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 that 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.

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`](https://searchfox.org/mozilla-central/rev/36a9249dc8543530eeab89df88f37dbab039f9d0/toolkit/components/find/nsFind.cpp#162-167). 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.