Closed Bug 1163238 Opened 9 years ago Closed 9 years ago

Orthogonal flow triggers "WARNING: have unconstrained inline-size; this should only result from very large sizes, not attempts at intrinsic inline-size calculation: 'NS_UNCONSTRAINEDSIZE != computedISizeCBWM && NS_UNCONSTRAINEDSIZE != availISizeCBWM'"

Categories

(Core :: Layout, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla41
Tracking Status
firefox40 --- affected
firefox41 --- fixed

People

(Reporter: dholbert, Assigned: jfkthame)

Details

Attachments

(3 files)

Attached file testcase 1
STR:
 1. Load testcase in a debug build.
  (The testcase just has a fixed-size div, with "writing-mode: vertical-lr")

 2. Look at your terminal output.

ACTUAL RESULTS:
This warning:
{
WARNING: have unconstrained inline-size; this should only result from very large sizes, not attempts at intrinsic inline-size calculation: 'NS_UNCONSTRAINEDSIZE != computedISizeCBWM && NS_UNCONSTRAINEDSIZE != availISizeCBWM', file layout/generic/nsHTMLReflowState.cpp, line 2403
}

This happens when we set up a nsHTMLReflowState for the element with the vertical writing mode.  We have availISizeCBWM == NS_UNCONSTRAINEDSIZE because there's unconstrained height.

I think the warning is bogus -- or rather, it indicates a situation that we should be checking for, & falling back to the viewport's size. The writing-mode spec section on "Available Sizes in Orthogonal Flows" says:

According to http://dev.w3.org/csswg/css-writing-modes/#orthogonal-auto :
  # Putting a box in an orthogonal flow allows [...] the available
  # inline size to be indefinite. [...] In these cases, the initial
  # containing block’s size is used as a fallback variable in place
  # of the available inline size for calculations that require a
  # definite available inline size.
(In reply to Daniel Holbert [:dholbert] from comment #0)
> This happens when we set up a nsHTMLReflowState for the element with the
> vertical writing mode.  We have availISizeCBWM == NS_UNCONSTRAINEDSIZE
> because there's unconstrained height.

Actually, in this case the origin of the warning isn't precisely that; it's an unconstrained *width* that is firing the warning.

This happens because we set available block-size to unconstrained for the orthogonal block's reflow state (to avoid potentially incomplete reflow, as we don't support fragmenting an orthogonal flow -- see bug 1152941). But then during InitConstraints, we're working in the containing block's writing mode (horizontal, in this case), and the vertical block's unconstrained available block-size (i.e. width) maps to unconstrained inline-size from the point of view of its container.

I think we can fix this by not resetting the available block-size to unconstrained until the end of the Init method, after we've done the constraint computations etc.
This fixes the problem (and warning) in common cases such as your example here. (Though there are still other scenarios where similar warnings occur for differnet reasons.)
Attachment #8613968 - Flags: review?(dholbert)
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
Looks like we're currently using this incorrectly-unconstrained available inline size when determining auto margins.  Here's a testcase demonstrating that (with huge margins in current nightly, and a viewport that's ~nscoord_MAX wide I think).

It's nicely centered in a build with your patch applied. Could you include a reftest that's along these lines?
Comment on attachment 8613968 [details] [diff] [review]
Don't set available block-size to unconstrained for orthogonal-block reflow state until after InitConstraints etc

r=me, with a reftest included, per previous comment.
Attachment #8613968 - Flags: review?(dholbert) → review+
(Thanks for fixing this!)
Pushed, along with a reftest based on your testcase.
https://hg.mozilla.org/mozilla-central/rev/272c05b16d76
https://hg.mozilla.org/mozilla-central/rev/3cbe1f9d3557
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
You need to log in before you can comment on or make changes to this bug.