1766304 - position:absolute svg elements get wrong static position in orthogonal writing-mode scenario, due to reporting incorrect intrinsic size

Status: NEW

(Core :: SVG, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

dshin noticed that SVG elements get the wrong position in abspos orthogonal-writing-mode scenarios (if they lack an explicit pixel-valued width/height), because we report the wrong intrinsic size.

If the SVG height and width attributes are missing or percent-valued, then SVGOuterSVGFrame::GetIntrinsicSize returns an intrinsic size of 0,0; but later on, we end up sizing the element to be 300x150 (kFallbackSize, via fallbackIntrinsicSize in nsContainerFrame::ComputeSize) when we actually lay it out.

This ends up producing the wrong layout, as shown in the attached testcase.

STR:

1. Load attached testcase.

EXPECTED RESULTS:
The two blue boxes should be at the same horizontal position (100px from the left edge of the viewport).

ACTUAL RESULTS:
The lower blue box is mispositioned; its right edge is at the spot where its left edge should be.

This is due to similar issue to what was discussed in bug 1765654 comment 1. We use GetIntrinsicSize to determine the frame's hypothetical position, and GetIntrinsicSize returns a width of 0 in this case; and then the frame ends up with a nonzero size, so it turns out the hypothetical position that we chose is wrong.

The zero vs. nonzero size comes into play due to the fact that we have to convert between writing modes in ReflowInput::CalculateHypotheticalPosition when reasoning about the origin placement -- specifically here:

    origin =
        origin.ConvertTo(cbwm, wm, reflowSize - boxSize.GetPhysicalSize(wm));

https://searchfox.org/mozilla-central/source/layout/generic/ReflowInput.cpp#1447-1448