1536143 - Text at www.realestate.co.nz overlaps

Status: NEW

(Core :: Layout, defect, P5)

Description

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Attachment: ExampleOfIssue.png

STR:

• Visit a listings page at www.realestate.co.nz, e.g. https://www.realestate.co.nz/residential/sale?by=featured&lct=s119&ql=20
• Notice that the text on the listings overlaps. See attached screenshot sections showing the issue highlighted.

This is a regression. Smallest window I could get from Mozregression: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=91fc3a79606bdc7fb43fef12eff7e65b5b84c00e&tochange=ea747bb2ffb77d1fd62b5fa6217cbee15b73d31f

Comment 1

[Emilio Cobos Álvarez (:emilio)]

Setting layout.css.moz-document.url-prefix-hack.enabled=true fixes it. So the good thing is that this is not broken on release. The bad thing is that they're using @-moz-document to workaround some sort of interop issue:

@-moz-document url-prefix() {
.listing-details .row::before {
display:block
}
}

Whereas otherwise it has:

.row::after, .row::before {
display: table;
content: ' ';
}

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Attachment: Reduced test-case.

Blink shows the text to the top, Gecko to the bottom. I still haven't dug into who's right.

Comment 3

[Mats Palmgren (inactive)]

Attachment: Testcase #2

Changing content: " " to content: "X" makes Chrome render it
the same as Gecko. Alternatively, adding * { vertical-align: top }
instead also makes both UAs render it the same.
So the issue seems to be a baseline-alignment difference when
content is just whitespace.

Comment 4

[Mats Palmgren (inactive)]

Attachment: Testcase #3c (further reduced)

Comment 5

[Mats Palmgren (inactive)]

Attachment: Testcase #3d (same as #3c, but with ::before/::after replaced by a <span> with the same content)

This should render the same as #3c. It does in Firefox, but not in Chrome.

Comment 6

[Mats Palmgren (inactive)]

So, I suspect the original issue that the text is at the top
in Chrome is simply a bug in Chrome. It doesn't seem like
a reasonable result from baseline-alignment. (that they render
#3c and #3d differently is also a strong indication of a bug)

Testcase #3d shows that there's a second issue: we handle an
empty table in the first line when baseline-aligning differently.
It appears Chrome skips it and we don't. (This should probably
be spawned off a separate bug).

Comment 7

[Sean Voisen (:svoisen)]

Bulk moving bugs that have been triaged P4 to P5 (P4 is reserved for WPT bugs).