From 21d3411b0cb027225f600642ce43811003a4ea49 Mon Sep 17 00:00:00 2001 From: Andy Date: Sat, 1 Aug 2020 20:54:54 -0700 Subject: Issue mcp-graveyard/UXP#1619 - Add Vertical Writing Testcase Ensures aspect ratio numerator and denominator aren't swapped in vertical writing modes. https://bugzilla.mozilla.org/show_bug.cgi?id=1548768 --- layout/generic/nsFrame.cpp | 20 -------------------- 1 file changed, 20 deletions(-) (limited to 'layout/generic') diff --git a/layout/generic/nsFrame.cpp b/layout/generic/nsFrame.cpp index afbd57f526..72923c4b7f 100644 --- a/layout/generic/nsFrame.cpp +++ b/layout/generic/nsFrame.cpp @@ -5197,26 +5197,6 @@ nsFrame::ComputeSizeWithIntrinsicDimensions(nsRenderingContext* aRenderingConte if (hasIntrinsicISize) { tentISize = intrinsicISize; } else if (hasIntrinsicBSize && logicalRatio) { - // (dholbert) - // This is wrong -- this ApplyTo call (and probably every ApplyTo call - // in this function) would only be valid if we're in a horizontal - // writing mode. It's not valid in a vertical writing mode. If this - // doesn't break tests, that's a bit concerning, and I think it means - // we're missing some test coverage. (That, or I'm misreading things.) - // - // aIntrinsicRatio is stored in terms of physical axes (width/height), - // either of which could be I vs. B axis. So any sort of - // aIntrinsicRatio.ApplyTo(someBSize) operation will be - // potentially-bogus. - // - // You probably want to bring back a logicalRatio variable - // (like the one we used to have here), but now with type AspectRatio. - // It would be equal to either aIntrinsicRatio or - // aIntrinsicRatio.Invert() depending on whether aWM is horizontal or - // vertical. (And hopefully having logical in its name would be a - // reminder that it's in terms of Inline/Block and can be used for - // these sorts of ApplyTo(intrinsicBSize) operations. tentISize = logicalRatio.ApplyTo(intrinsicBSize); } else if (logicalRatio) { tentISize = aCBSize.ISize(aWM) - boxSizingToMarginEdgeISize; // XXX scrollbar? -- cgit v1.2.3