1603354 - Ruby in Firefox 71 is displaying incorrectly.

Status: RESOLVED FIXED

(Core :: Layout: Ruby, defect, P3)

Description

[mw]

Attachment: Screenshot_2019-12-10_Copyeditors_Diff_--_Debugging_Page.png

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:71.0) Gecko/20100101 Firefox/71.0

Steps to reproduce:

This is a sudden change that happened following an update to Firefox 71 on Ubuntu, which made some instances of <ruby> text start behaving in erratic ways. When I tried looking it up to see if it was only an issue on my end, a lot of the examples I found also seemed also have different output from what should be expected.

I'm looking up workarounds to what I needed it for, but the documentation no longer matching the anticipated results does seem like a bigger issue. Sadly, East Asian languages are not quite my expertise, so more clear examples might be seen in the following:
https://www.w3.org/TR/ruby/#presentation
https://www.w3.org/International/articles/ruby/markup#partial_overlap

Actual results:

Following Firefox 71, <rtc> positioning has to be explicitly defined in CSS and is no longer implicit through order.

Ruby elements with two <rtc> elements or just a <rt> and <rtc> without any base text now collapses in on itself. (Though this does get fixed if an empty <rbc> element is introduced.)

The instance of multiple, augmented <rb>-to-<rt> seems to break down where a single <rt> would end up covering the entire width of the <rbc>, even if multiple <rb>s are established. The rbspan attribute doesn't seem to affect or prevent this. Removing both <rbc> and <rtc> fixes things. The example from the W3C document would produce the correct result if re-written as thus: <ruby xml:lang="ja">
<rb>斎</rb>
<rb>藤</rb>
<rb>信</rb>
<rb>男</rb>
<rt>さい</rt>
<rt>とう</rt>
<rt>のぶ</rt>
<rt>お</rt>
<rtc style="ruby-position:under;">
W3C Associate Chairman
</rtc>
</ruby>

Expected results:

Before Firefox 71, <rtc> order followed with ruby-positon: over; and then ruby-position: under; -- all Ruby documentation I've been able to find suggests this is should be what happens normally, without the need for CSS.

Ruby elements with <rtc>s, <rt>s, but no <rb>s or <rbc>s would naturally size and position themselves to match with the rest of the paragraph styling.

Comment 1

[mw]

Comment on attachment 9115388 [details]
Screenshot_2019-12-10_Copyeditors_Diff_--_Debugging_Page.png

Looking into this more, this example I provided might have more to do with the fact that <rtc>'s default ruby-position CSS is no longer determined by order than it is the "no-base-text ruby element collapsing in on itself" mentioned in the original comment. Prodding it further, these are two sides of the same problem.

Comment 2

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Hi,

Thanks for submitting this bug to us!

I was unable to reproduce this issue on my end (on your examples provided), I tried on Ubuntu 18.04.3 LTS with Firefox Nightly version 73.0a1 (2019-12-23) (64-bit).

Does this issue occur with a fresh profile as well? You can find the steps here: https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles?redirectlocale=en-US&redirectslug=Managing-profiles#w_starting-the-profile-manager

You can also try testing if the issue is reproducible in safe mode, here is a link that can help you:
https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

Or you can also download Firefox Nightly from here: https://nightly.mozilla.org/ , to see if the issue still occurs there as well.

If after doing this you can still reproduce the bug, would you send a video of the bug?

Thanks in advance. I've already chosen a component for this bug in hope that someone with more expertise may look at it. We'll await their answer.

Best regards, Clara.

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Could you attach an example HTML file that shows the bug? (I'm not sure what examples Clara tested, either.) But in both cases (comment 0 and comment 2), it's extremely helpful to attach what you're testing so that other people can easily replicate your results later (and thus tell if the bug is still present).

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'd also note that the only ruby change in Firefox 71 was bug 1565681; a change between 70 and 71 seems likely to have resulted from that.

Comment 5

[mw]

I've been able to replicate the bug for Firefox 71 on Windows as well. I've isolated the code in question as HTML here: http://media.revasser.net/store/moz/firefoxrubybug.html

The two Japanese-language examples are complex Ruby structures lifted from the W3C's Ruby definitions. The text is how they currently display, and the image file is a capture of how they should display. The first <rtc> should have the ruby-position: over; innate, and the second <rtc> would need to be ruby-position: under; -- but now each <rtc> is always defaulted to the over position recursively.

The English-language use-case for ruby text which I originally discovered the bug, though I've since applied fixes for it by other means. It's possible some CSS errors that I made were always there and simply were revealed by the change in 71, so it might be wise to ignore them. (You can see them here: http://media.revasser.net/store/moz/) In either case, the Japanese use-cases are more important, as those are the ones which define the majority of the documentation on HTML5 rubytext that I've been able to find.

Comment 6

[mw]

As a note, following the change I've been able to fix the display errors on the systems I need by forcing the CSS properties for ruby-position in each instance. It was an easy fix in my own use-cases, but the only reason it seemed important to report it here was that the examples from most of the common <ruby> documentation sources also seemed a bit off following the change as well. (Especially with regards to the W3C's internationalization documentation.)

Of course, the documentation on HTML5 <ruby> has never been super-good, especially in English, so it's entirely possible I've just been mistaken this entire time. Apologies if that turns out the case.

Here's a cleaner case of the original context I found.

<p id="no-copyediting'>InsertSpace</p>
<p id="pre-71-regular">Insert<ruby style="margin-left: -0.25em; margin-right: -0.25em;"><rtc>#</rtc><rtc>^</rtc></ruby>Space</p>
<p id="forced-but-collapsed">Insert<ruby style="margin-left: -0.25em; margin-right: -0.25em;"><rtc style="ruby-position: over;">#</rtc><rtc style="ruby-position: under;">^</rtc></ruby>Space</p>
<p id="post-71-corrected">Insert<ruby style="margin-left: -0.25em; margin-right: -0.25em;"><rbc></rbc><rtc style="ruby-position: over;">#</rtc><rtc style="ruby-position: under;">^</rtc></ruby>Space</p>

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: partly simplified testcase

This is very partly simplified from the first example in http://media.revasser.net/store/moz/ . Note that the fonts probably don't work when uploaded this way (or from a file URL).

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

When comparing the behavior of Firefox 70 and Firefox 71 on that testcase, I don't see one of the differences between your screenshot in comment 0: whether the fourth or fifth character (which "s" in "thiss") is struck through. I see the other differences, though.

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

mozregression reports this regression range, which isn't at all surprising.

Comment 10

[Xidorn Quan [:xidorn] UTC+10]

Attachment: simplest case

So, what happens here is that the ruby base container is empty in the testcase, which causes it to have zero height, and the annotations would be positioned accordingly.

Previously, ruby base containers are always sized as a normal inline element, so it would always have height from the font metrics. Bug 1565681 changes it to match the spec that it becomes exactly contain all ruby bases inside it. However, this doesn't take the case that it's being empty into account.

This attached file is the simplest way to see the change of behavior.

I've raised a spec issue for this with a proposed solution to make ruby base containers behave like normal inline element when it's empty.

I'm not quite sure the way you are using ruby is expected, but I do think it makes sense that ruby base container should always have size. I'll probably submit a patch later, so keep my ni? for now.

In the mean time, a workaround is to make the ruby base container not empty by inserting a <rb></rb> before your innermost <rt>s.

Comment 11

[Boris Chiou [:boris]]

Set P3 for now and I guess xidorn may take a look at this.

Comment 12

[Xidorn Quan [:xidorn] UTC+10]

Attachment: Bug 1603354 - Treat empty ruby base/text container as if there is an empty inline element inside. r?dholbert

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/045c89271c06
Treat empty ruby base/text container as if there is an empty inline element inside. r=dholbert

Comment 14

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/21458 for changes under testing/web-platform/tests

Comment 15

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.

Comment 16

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/045c89271c06

Comment 17

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by jgraham