Filing this bug for this LQC-discovered bug:
http://warfa.cs.washington.edu:8001/api/bug_file/bug-report-2021-09-29-09-22-44-781646/min_bug_with_debug.html?state=dirty
http://warfa.cs.washington.edu:8001/api/bug_file/bug-report-2021-09-29-09-22-44-781646/min_bug_with_debug.html?state=reloaded

(Those^ URLs don't produce the same rendered output right now -- 'porro' wraps to a newline in the second one -- and that's the bug.)

Minimal testcase attached, reference case coming up next (though I'm not entirely sure which is actually correct).

Here's a screenshot showing current Nightly's rendering of the two attachments, which disagree with each other even though they shouldn't.

Incidentally, Chrome renders both of these files with all of the content on a single line (and with the black box being one line tall, rather than 2).

Regression range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=19fc512f3c95b2f24edefbf6ee87a7bf63e618d1&tochange=595b7807fb110bbb87717938a2f85bd083b608f3

(Before this range, we reliably render of the attachments like the left half of my screenshot -- with a b on the same line.)

In that range, this looks most-related to Bug 1064172, I think; probably a regression from that bug. jfkthame, maybe you'd be interested to take a look?

Interesting.... so the discrepancy is clearly a bug (note that if you zoom in/out on the testcase, triggering a full reflow, it "fixes" itself to match the reference) where we're failing to reflow sufficiently in response to the style change.

As for what the correct rendering should be: I'm inclined to think Firefox is right to wrap onto two lines, though I haven't trawled through specs to see if this is clearly specified anywhere. The codepen at https://codepen.io/jfkthame/pen/xxrBEro shows a distinct lack of interop in a related example:

• Firefox and Safari agree about the initial rendering of both columns, while Chrome is quite different
• If you click the button to make the red spans transparent, Safari unexpectedly changes the layout of the left column
• Using the second button to add CSS outlines to the spans (which should not affect layout at all) restores the expected layout in Safari

I think Chrome is wrong to totally ignore the empty span when line-wrapping -- as the codepen shows, this happens even when it has visible width of its own (due to padding), it's not just about the margin -- and Safari is clearly wrong to somehow "optimize away" the span only when it has no visible rendering; it's still equally present for layout purposes.

So I don't think this is really a regression from bug 1064172; that just exposes a pre-existing issue more widely. This version of the testcase exhibits the same behavior (incorrect initial rendering; fixes itself on reflowing, e.g. with zoom) on even older versions of Firefox.

Using the modified testcase (comment 5) I get a "regression" range of https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6e3ec93efe1d&tochange=bf0e76f2a7d4, though arguably it's still not really a regression: that range includes bug 709014, prior to which we simply didn't honor the margin on the inline element at all.

Here's a further-modified testcase (the inline element has padding -- and therefore width -- instead of margin) that exhibits the same reflow inconsistency in even older releases: it reproduces all the way back to mozilla-5, at least.

Hmm, so this seems to happen only if the test element contains some whitespace (although it will disappear due to whitespace collapsing). Note that the testcase has

  <div id="test"></span>

so although at a glance, the id=test element looks empty, it's not, because the (mismatched) </span> tag doesn't close it.

If you change it to <div id="test"></div>, the issue doesn't occur; but insert a space, <div id="test"> </div>, and it comes back.

Thanks for taking a look! (I did notice the </span> mistake after posting but didn't want to cause bugspam just to repost and fix that. I didn't realize that this typo was actually relevant for reproducibility. :) )

By the way, I'm currently thinking that the initial Firefox rendering, where "a b" is on the first line and the (invisible) inline element is wrapped to a second line may be the most sensible result, and the reflowed result we see after zooming, where the "b" wraps to the second line, is incorrect. But it's not entirely clear to me how to read the specs here.