STR:

1. Load attached testcase.

EXPECTED RESULTS:
Lime square should be visible, with text "You should see me".

ACTUAL RESULTS:
No lime square is visible.

If I add any additional content to the ruby-text element (even a single space character before or after the abspos thing), then we pass the test.

This is the sole reason that we fail this WPT test:
https://wpt.fyi/results/css/css-contain/contain-layout-005.html

(The test is categorized as CSS containment, but our failure has nothing to do with CSS Containment.)

We're skipping the paint due to the IsAutoHidden() (i.e. NS_RUBY_TEXT_FRAME_AUTOHIDE) early-return in nsRubyTextFrame::BuildDisplayList:

void nsRubyTextFrame::BuildDisplayList(nsDisplayListBuilder* aBuilder,
                                       const nsDisplayListSet& aLists) {
  if (IsAutoHidden()) {
    return;
  }

  nsRubyContentFrame::BuildDisplayList(aBuilder, aLists);
}

https://searchfox.org/mozilla-central/rev/4606c7974a68cab416c038acaedcae49eed93822/layout/generic/nsRubyTextFrame.cpp#52-54

For the element to show up, we have to get past that early-return, because we use the placeholder frame [a child of the nsRubyTextFrame] to do the painting, IIRC, even though the abspos element's primary frame has a parent that's further up in the frametree.

If I remove that check, then this bug's testcase renders as I'd expect it to (with the abspos element visible), and the contain-layout-005.html test renders as-expected (green), too.

Regression range, using attached testcase:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cafb1c90f794a73100a8f0afb9fe3301df0f2bde&tochange=fb720c90eb49590ba55bf52a8a4826ffff9f528b

--> Regression from:
f4ba4b6e7c951960588c09971726d653845220be Xidorn Quan — Bug 1197765 - Compare text content inside frame instead of the content node for ruby autohiding. r=dbaron

Though it looks like the autohiding feature in general was added earlier in bug 1052123 (in a way that didn't yet break this testcase until Bug 1197765 landed).

It looks like the spec text for this feature is https://drafts.csswg.org/css-ruby-1/#autohide
...and it's not obvious to me if / how it is supposed to impact abspos content.

Note: from a DOM/JS perspective, if I query the .textContent of the <span> in the attached testcase (the thing with display:ruby-text), devtools gives me back the text of its abspos descendant. So that leads me to believe that the abspos element's text should be included in the should-we-autohide comparison here (and that should end up convincing us not to autohide).

(In reply to Daniel Holbert [:dholbert] from comment #4)

Note: from a DOM/JS perspective, if I query the .textContent of the <span> in the attached testcase (the thing with display:ruby-text), devtools gives me back the text of its abspos descendant. So that leads me to believe that the abspos element's text should be included in the should-we-autohide comparison here (and that should end up convincing us not to autohide).

On the other hand, the spec says that the should-we-autohide comparison "...considers only the textContent of the boxes"

I don't know if "textContent of boxes" is a meaningful/well-defined term in the face of abspos content. In this case, the text node is a descendant of the ruby-text element, but the text boxes are not descendants of the ruby-text-box.

So, it's kinda unclear what's supposed to happen. xidorn, do you have any opinions and do you recall if this is a scenario we considered? (abspos stuff intermixed with the content being compared for equality & potentially being inadvertantly autohidden)

Interestingly, there was a discussion a long time ago specifically around this: [css-ruby] Autohiding and out-of-flow elements.

The conclustion at that time is that the comparison do include out-of-flows (and even display: none, see below), but spec editors are happy to align with implementations for whatever easier, since there is no reasonable usecase for that.

In this specific case, I think it may make sense to include out-of-flows, and it wouldn't create too much extra complexity either: just have nsLayoutUtils::AppendFrameTextContent traverse through placeholders should be enough.

It is a different story for display: none, though, that it may not even work conceptually. It's not clear to me that if we exclude display: none from the text comparison, whether it still makes sense to compare out-of-flows. I'll file a spec issue to discuss.

(Keep the ni? for filing the spec issue)

https://github.com/w3c/csswg-drafts/issues/3972

(In reply to Xidorn Quan [:xidorn] UTC+11 from comment #7)

https://github.com/w3c/csswg-drafts/issues/3972

Adding that as see-also, and clearing no-longer-relevant version-specific status flags.