Closed
Bug 1420787
Opened 7 years ago
Closed 2 years ago
Firefox resolves percentages against wrong box on abspos containing block, when intrinsically sizing %-height <img>/<canvas> in %-height abspos parent
Categories
(Core :: Layout: Positioned, defect, P3)
Core
Layout: Positioned
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: elskede, Unassigned)
References
Details
Attachments
(3 files)
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.
Summary: Image & link seen in reader view but not standard view. → Webpage image & link seen in reader view but not standard view.
Updated•7 years ago
|
Component: Untriaged → Reader Mode
Product: Firefox → Toolkit
Comment 1•7 years ago
|
||
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&h=1275.0&w=1700&fit=max&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? :-)
Component: Reader Mode → Layout
Flags: needinfo?(dholbert)
Product: Toolkit → Core
Comment 2•7 years ago
|
||
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•7 years ago
|
||
Here's a reduced testcase (using a teal <canvas> instead of an img, for brevity/convenience).
Updated•7 years ago
|
Attachment #8934610 -
Attachment description: reduced testcase 1 (teal in Chrome, no teal in Firefox) → reduced testcase 1 (teal in Chrome, Safari, Edge; no teal in Firefox)
Comment 4•7 years ago
|
||
Here's a testcase with a non-zero content height on the abspos containing block.
Flags: needinfo?(dholbert)
Comment 5•7 years ago
|
||
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Webpage image & link seen in reader view but not standard view. → Firefox resolves percentages against wrong box on abspos containing block, when intrinsically sizing %-height <img>/<canvas> in %-height abspos parent
Updated•7 years ago
|
Priority: -- → P3
Updated•6 years ago
|
Webcompat Priority: --- → ?
Component: Layout → Layout: Positioned
OS: Unspecified → All
Hardware: Unspecified → All
Version: 58 Branch → Trunk
Updated•6 years ago
|
Webcompat Priority: ? → revisit
Comment 7•2 years ago
|
||
The testcases work for me now, so we'll assume this is fixed.
Status: NEW → RESOLVED
Closed: 2 years ago
Webcompat Priority: revisit → ---
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•