1400958 - Text stomps on float with negative margin (with margin negative enough to zero out margin-box size)

Status: VERIFIED INVALID

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

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

STR:
 1. Load attached testcase.

ACTUAL RESULTS:
 Text overlaps the purple floated element.

EXPECTED RESULTS:
 No overlap.


The attached testcase is reduced from the affected page on this webcompat issue:
 https://github.com/webcompat/web-bugs/issues/9957
...which is http://plain-text.co/ . As noted over there, the title & book-cover-image overlap, which seems to be due to this bug.

Comment 1

[Daniel Holbert [:dholbert]]

The setup here is a float whose margin-box size is zero (due to having a negative margin-right or margin-left, which is sufficiently negative to cancel out the "width").

Normally text will stop when it hits the edge of the float.  But when the margin-box size is reduced to 0 like this, we don't seem to treat the float as occupying any space at all, and the text just runs right through it.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: approximate reference case 1 (I tweaked the float's "margin-right" by 1px)

So the testcase had this on the float:
 width: 50px;
 margin-right: -50px;

Here's a reference case where I've reduced the magnitude of the 'margin-right' down to -49px, so that we end up with a barely positive margin-box size.  This gives EXPECTED RESULTS.

Comment 3

[Daniel Holbert [:dholbert]]

Comparing to other browsers:
Chrome 63, Edge 15, and Safari 10.1 all give EXPECTED RESULTS on the testcase here.

Firefox 55 and 57 give ACTUAL RESULTS.  (Probably other older versions for quite a while, too.)

Comment 4

[Daniel Holbert [:dholbert]]

BTW, I confirmed that Nightly 2010-01-01 ("version 3.7a1pre") behaves like current Firefox builds on the attached testcases. So indeed, this is not a regression.

Comment 6

[Sean Voisen (:svoisen)]

ni? myself to bring up in next webcompat triage

Comment 7

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 8

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.

Comment 9

[Daniel Holbert [:dholbert]]

Note, https://bugs.chromium.org/p/chromium/issues/detail?id=1141209 is a closely-related issue -- we get some webcompat.com bug reports in this area (floats with negative margins and flexbox) that really boil down to sites accidentally depending on that Chrome bug.

Comment 10

[Daniel Holbert [:dholbert]]

Chrome 98 actually matches our rendering here, on the attached "testcase 1".

(Safari 15.1 still renders testcase 1 differently from us, with text wrapping when it runs into the float, like it does in the approximate-reference-case.)

Comment 11

[Daniel Holbert [:dholbert]]

In fact, Chrome 76 (released in 2019) and newer versions seem to all match our rendering of testcase 1. Chrome 75 and earlier matches Safari 15.1.

Without having dug into the relevant specs/code, I don't know for absolute sure who's correct. But given that Chrome is the only browser engine that's been observed to have changed behavior here, it feels reasonable to suspect that their newer behavior (which matches our behavior) is correct.

And at a minimum, this doesn't present as much of a webcompat issue for us, now that we're not on our own.

Given that I'm the reporter, I'm not going to feel too bad about closing this as INVALID, in the sense that our behavior is now probably-correct (and/or required for compatibility, given that the dominant rendering engine matches us on this now).

I think the webcompat reports that have been linked here in recent years (since Chrome 76) are most-likely cases where sites are depending on https://bugs.chromium.org/p/chromium/issues/detail?id=1141209 , which is also about floats and negative margins.

The relevant difference is:

• In this bug here, the testcase has a float with a negative margin
• in the chrome bug, the testcase has a float next to something with a negative margin (but the float itself is not the thing with the negative margin).

Comment 12

[Daniel Holbert [:dholbert]]

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

I think the webcompat reports that have been linked here in recent years (since Chrome 76) are most-likely cases where sites are depending on https://bugs.chromium.org/p/chromium/issues/detail?id=1141209

(for completeness: the corresponding webkit bug is https://bugs.webkit.org/show_bug.cgi?id=233956 )

Indeed, I just went through & confirmed that the last 6 webcompat reports here are in fact cases where the site is (or was) depending on that Chromium/WebKit bug:

https://webcompat.com/issues/55377
https://webcompat.com/issues/58830
https://webcompat.com/issues/61521
https://webcompat.com/issues/67410
https://webcompat.com/issues/75137
https://webcompat.com/issues/74190

(The next-older webcompat report is locked & I can't add comments, so I didn't dig in further there or in older issues.)

Comment 13

[Daniel Holbert [:dholbert]]

I've filed bug 1745310 to have a place to track/aggregate webcompat issues related to the Chromium/WebKit bug discussed in comment 11 and 12 here.

I moved the 6 webcompat.com reports from comment 12 over to be "see also" on that new bug report.

Comment 14

[Daniel Holbert [:dholbert]]

As discussed in bug 1745310 comment 9 through 12: after some further digging, it seems the Chrome behavior is sensible here, and I think we should match it.

Hence, it doesn't make sense for this bug to be closed as 'invalid'; I'll dupe this against bug 1745310 (where the work will probably happen) instead.

Comment 15

[Daniel Holbert [:dholbert]]

Sorry, I think I was slightly-confused in comment 14; I had forgotten that this bug here is still INVALID for reasons discussed in comment 11.

(In comment 14, I was mostly meaning to say that bug 1745310 is valid, and I now have a patch there; but that patch doesn't change our rendering on the testcase here, which is in fact good, per comment 11.)