Out-of-flow boxes do not take left/right/top/bottom and margins into account when performing shrink-to-fit.

It looks like the "static" position itself is calculated correctly (i.e. in the case both sides are specified as auto), but the size may become wrong, as soon as shrink-to-fit is involved.

https://www.w3.org/TR/CSS22/visudet.html#abs-non-replaced-width

In the case where all three of left, right and width are auto, the spec just defines how to resolve left or right (depending on direction), and then jump to step 1 or 3 (depending on direction) for size resolution. Our implementation [1], on the other hand, actually sets the width as well. This is probably not wrong, but it IS code duplication.

It would probably be better to leave it at auto and let step 1 or 3 take care of calculating it, like the spec suggests, and do it correctly there: need to subtract resolved left / right and non-auto margins. This isn't done today.

I played a little with the code, and when I attempted to fix it, I got some regressions elsewhere. I think it's because of the direction property. In some cases we need to use the direction of the "static" (i.e. nearest) container, while in other cases we should use that of the containing block. We currently always use that of the containing block. But I didn't really investigate this thoroughly.

[1] ComputeAbsoluteHorizontal in ng_absolute_utils.cc

This bug is responsible for the failure of fast/block/positioning/059.html (and other tests too, I think). Although it kind of passes (according to its pass condition text), it doesn't match the expectation, because the absolutely positioned BODY element becomes 8px too wide (because it doesn't subtract the 8px left margin when calculating the width).
 

Deleted: tc.html 765 bytes

tc.html 765 bytes View Download

Deleted: tc2.html 372 bytes

tc2.html 372 bytes View Download