We shouldn't use "flex-basis" for sizing children of a -webkit-box

RESOLVED FIXED in Firefox 57

Status

()

Core
Layout
RESOLVED FIXED
3 months ago
2 months ago

People

(Reporter: dholbert, Assigned: dholbert)

Tracking

Trunk
mozilla57
Points:
---

Firefox Tracking Flags

(firefox57 fixed)

Details

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(2 attachments)

(Assignee)

Description

3 months ago
In bug 1382252, we've got a legacy -webkit-box container, whose child ends up unfortunately being 0 sized.

We size the child to 0 because:
 (1) We emulate the -webkit-box container using nsFlexContainerFrame
 (2) For children of a nsFlexContainerFrame, we use "flex-basis" instead of "width" when determining their desired size.
 (3) And in this case, the child happens to have "flex-basis: 0" (via the "flex" shorthand).

So the child ends up being 0-sized. :(

We shouldn't be using "flex-basis" at all in this case -- we should ignore it and use 'width' instead.  (Or equivalently, behave as if it were at its default value "auto", which would also make us use 'width'.)

I have patches for this already -- I'll post them shortly.
(Assignee)

Updated

3 months ago
Assignee: nobody → dholbert
Status: NEW → ASSIGNED
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)
(Assignee)

Comment 3

3 months ago
Mats, if you wouldn't mind reviewing this when you're back, that would be awesome. :)  (MozReview seems to have dropped the review request, probably because you're on vacation.)
Flags: needinfo?(mats)
(Assignee)

Updated

3 months ago
Blocks: 1316057

Comment 4

2 months ago
mozreview-review
Comment on attachment 8893504 [details]
Bug 1387152 part 1: Adjust indentation and use HasAnyStateBits() instead of manual bitwise arithmetic, in nsFrame size-computation code.

https://reviewboard.mozilla.org/r/164598/#review178630
Attachment #8893504 - Flags: review+

Comment 5

2 months ago
mozreview-review
Comment on attachment 8893505 [details]
Bug 1387152 part 2: Don't let unrelated property "flex-basis" influence the sizing inside of -webkit-box containers.

https://reviewboard.mozilla.org/r/164600/#review178632
Attachment #8893505 - Flags: review+
(Assignee)

Comment 6

2 months ago
Thanks! I triggered a try run via MozReview, and I'll land assuming that succeeds.
Flags: needinfo?(mats) → needinfo?(dholbert)
(Assignee)

Comment 7

2 months ago
(just circling back to this)

My Try run had some failures in dom/tests/mochitest/general/test_interfaces.html (failures like "ByteLengthQueuingStrategy should NOT be defined on the XBL scope" and "DANGER, are you sure you want to expose the new interface ByteLengthQueuingStrategy to all webpages as a property on the window") -- but I'm sure those are unrelated to this patch. I must've been based on top of an iffy cset that was backed out or fixed soon after it landed, and I just got unlucky enough to stack my patches on top of it before the backout.

Anyway -- reftests look good (aside from a few unrelated tests that are failing due to rendering entirely-blank, which have intermittent bugs filed already).  So, I'll go ahead and land.
Flags: needinfo?(dholbert)

Comment 8

2 months ago
Pushed by dholbert@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/929f225ca720
part 1: Adjust indentation and use HasAnyStateBits() instead of manual bitwise arithmetic, in nsFrame size-computation code. r=mats
https://hg.mozilla.org/integration/autoland/rev/d5110841090c
part 2: Don't let unrelated property "flex-basis" influence the sizing inside of -webkit-box containers. r=mats
(Assignee)

Updated

2 months ago
Duplicate of this bug: 1316057
https://hg.mozilla.org/mozilla-central/rev/929f225ca720
https://hg.mozilla.org/mozilla-central/rev/d5110841090c
Status: ASSIGNED → RESOLVED
Last Resolved: 2 months ago
status-firefox57: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
(Assignee)

Updated

2 months ago
No longer blocks: 1382252
Duplicate of this bug: 1382252
You need to log in before you can comment on or make changes to this bug.