1420787 - Firefox resolves percentages against wrong box on abspos containing block, when intrinsically sizing %-height <img>/<canvas> in %-height abspos parent

Status: RESOLVED WORKSFORME

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

Description

[elskede]

Attachment: Screen Shot 2017-11-26 at 9.39.41 PM.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20171126220311

Steps to reproduce:

Click on any startup link on https://betalist.com. For instance, https://betalist.com/startups/timeboostapp


Actual results:

In standard view it loaded a title at the top, a paragraph of text at the bottom, and a big white blank in the middle. 

In reader view it loaded a title at the top, a paragraph of text at the bottom, and a graphic in the middle that is a link to the startup website. 


Expected results:

In standard view it loaded a title at the top, a paragraph of text at the bottom, and a graphic in the middle that is a link to the startup website. 

Loaded as expected.

Comment 1

[:Gijs (he/him)]

This isn't a reader mode bug as reader mode is functioning correctly.

The page isn't displaying as desired outside of reader mode because it has this HTML:

<div class="flickity-slider" style="left: 0px; transform: translateX(-16px);"><a class="carousel__item is-selected" style="position: absolute; left: 0px;" href="/startups/timeboostapp/visit"><img alt="Timeboostapp" src="https://betalist.imgix.net/attachment/72289/image/599861548f1800f5bc74c40313943076.jpg?ixlib=rb-1.1.0&amp;h=1275.0&amp;w=1700&amp;fit=max&amp;auto=format" class="flickity-lazyloaded">
</a></div>

And the following CSS:

.flickity-slider {
    position: absolute;
    width: 100%;
    height: 100%;
}

.carousel .carousel__item {
    height: 100%;
    display: block;
    overflow: hidden;
    position: relative;
}


It seems we're deciding that the overflow:hidden means that you don't get to see the contents of the <a> that has display: block.

On the other hand, it seems Chrome/Blink is deciding that (presumably because of display:block and despite it having position:absolute?) that the <a> has width:100% so you do get to see the image inside it.

I can trivially make the image display in Firefox by giving the <a> an inline width: 100%.

I don't know why we're doing something different from blink here, I'm not a layout-y person. :dholbert? :-)

Comment 2

[Daniel Holbert [:dholbert]]

This looks like it's some finicky intrinsic-sizing-of-images-inside-of-an-intrinsically-sized-element sort of thing.  I'll take a closer look at some point today.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase 1 (teal in Chrome, Safari, Edge; no teal in Firefox)

Here's a reduced testcase (using a teal <canvas> instead of an img, for brevity/convenience).

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase 2 (teal is skinny in Firefox, wide in other browsers)

Here's a testcase with a non-zero content height on the abspos containing block.

Comment 5

[Daniel Holbert [:dholbert]]

So the problem happens when we try to determine the intrinsic width of the <canvas> (or the <img> in the original page), as part of intrinsically sizing its abspos parent.

a) The canvas has an intrinsic aspect ratio and a specified height, so we try to back-compute the width from those.
b) So first, we need to resolve its height:100% -- and we resolve that against its parent's height, which also happens to be 100%, which we also need to resolve.
c) Here's where things go wrong. It seems that for this part of the algorithm, we resolve the parent's 100% height against its containing block's content-box height (i.e. the "height" property), which is right in the general case. But, it's wrong in this case, since the parent is abspos, which means it uses its containing-block's *padding box* rather than its content box. 
d) So we end up resolving <canvas>'s 100% height against the wrong value, basically, when we compute its intrinsic width.

Then later on during layout, we recompute the heights and we *do* correctly use the padding box for that part. But it's already too late to fix the miscalculated intrinsic width.

Note: this is not a regression -- I was able to reproduce it in builds from a few years ago, at least.

Comment 7

[Dennis Schubert [:denschub]]

The testcases work for me now, so we'll assume this is fixed.