1613576 - text overflow until image.src is specified inside a grid element

Status: RESOLVED INVALID

(Core :: Layout: Images, Video, and HTML Frames, defect)

Description

[Karl Dubost💡 :karlcow]

This can be reproduce on rdm with firefox desktop and a mobile user agent

1. Set rdm to 411 x 731
2. Choose a mobile ua string Mozilla/5.0 (Android 10; Mobile; rv:71.0) Gecko/71.0 Firefox/71.0
3. enter https://www.miekemosmuller.com/nl/blog/ernst-en-spel
4. observe how the text is wider than the viewport
5. scroll down
6. once we reach the image, the text fits the viewport

this is due to lazy loading. the placeholder for the image is

<p>
	<img class="LZY" alt="Mieke Mosmuller" data-src="https://www.miekemosmuller.com/dimages/Blog297.jpg">
</p>

with

.LZY {
	background: #F1F1FA;
	width: 400px;
	height: 300px;
	display: block;
	margin: 10px auto;
	border: 0;
}
img[data-src] {
	opacity: 0;
}
.CONTENT img, aside img {
	max-width: 100%;
}

As soon as programmatically image.src = image.dataset.src;, the max-width kicks in and set the size of the image to 381px.

Previously it was setting the image to 400px. Without the image.src the max-width had no effect on the img.

Comment 1

[Hiroyuki Ikezoe (:hiro)]

It looks like the behavior on Chrome is exactly same as Firefox.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Yeah, I'm not sure we're doing anything wrong here, given that Chrome agrees with us.

The behavior is a bit puzzling, though, so it merits some investigation. As a first step, here's a reduced testcase (with the image included as a data URI so that the testcase is standalone).

I've included two img tags - one without src and one with src (from before/after the scroll operation in the original page). The issue reproduces as long as the first img (without src) is present.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (more reduced)

Comment 4

[Daniel Holbert [:dholbert]]

Our behavior on the actual-rendered-<img> scenario is a direct and intended result of this changeset:
https://hg.mozilla.org/mozilla-central/rev/b34ebd7afb7811db1ef5ba36dc5c22153c99d5ce

Bug 823483 patch 4 - Make a percentage max-width override a fixed width for replaced element intrinsic size computation. r=dholbert

As discussed on that bug, our implementation there was partly for compat reasons (so it's not surprising that Chrome has this behavior as well, per comment 1). And it looks like this "graceful" behavior (introduced in that bug) was targeted to replaced elements & similar (e.g. some form controls).

In the affected site here: before the image loads, it renders as a block (because it's replaced with its alt-text due to not having image data yet, and since the site gives it display:block). And so, when its containing block (a grid area, several layers up the DOM) is sized to wrap its intrinsic size, it's effectively asking "What is the intrinsic size of my descendant block box with style="width:400px; max-width:100%"? And apparently the answer to that has always been 400px (and compat requires it), though we added a special case (for even-better compat) in bug 823483.

So bottom line, this is a website bug which is visible in all browsers, and not a Firefox bug.