Bugzilla

[dshin noticed](https://phabricator.services.mozilla.com/D144182#4723958) that SVG elements get the wrong position in abspos orthogonal-writing-mode scenarios (if they lack an explicit width/height), because we report the wrong intrinsic size.

If the SVG `height` and `width` attributes are percent-valued, then we report an intrinsic size of 0,0, but we end up using 300x150 (kFallbackSize) as the element's size 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

[dshin noticed](https://phabricator.services.mozilla.com/D144182#4723958) 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 percent-valued, then we report an intrinsic size of 0,0, but we end up using 300x150 (kFallbackSize) as the element's size 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

[dshin noticed](https://phabricator.services.mozilla.com/D144182#4723958) 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