Bug 1739260 Comment 3 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Original comment by
on 
My initial investigation on this bug:
`nsIFrame::ComputeSize()` (i.e. computed in the `childReflowInput`) return (0, 0) for the element with aspect-ratio when doing reflow for floats [1] because when we trying to put this element into the bottom-right available area, our flow available size is (0, 3000), so we use 0 as its available inline size in `nsIFrame::ComputeSize()`, and use 1/1 aspect-ratio, so the result is (0, 0). And then we stay in the do-while loop [1] forever. Still trying to figure why we don't break this loop and what is the expected behavior for this case.

[1] https://searchfox.org/mozilla-central/rev/5e15e00fa247cba5b765727496619bf9010ed162/layout/generic/nsBlockFrame.cpp#3858-3978
Revision 1 by
on 
My initial investigation for this bug:
`nsIFrame::ComputeSize()` (i.e. computed in the `childReflowInput`) return (0, 0) for the element with aspect-ratio when doing reflow for floats [1] because when we trying to put this element into the bottom-right available area, our flow available size is (0, 3000), so we use 0 as its available inline size in `nsIFrame::ComputeSize()`, and use 1/1 aspect-ratio, so the result is (0, 0). And then we stay in the do-while loop [1] forever. Still trying to figure why we don't break this loop and what is the expected behavior for this case.

[1] https://searchfox.org/mozilla-central/rev/5e15e00fa247cba5b765727496619bf9010ed162/layout/generic/nsBlockFrame.cpp#3858-3978
Revision 2 by
on 
My initial investigation for this bug:
`nsIFrame::ComputeSize()` (i.e. computed for `childReflowInput`) return (0, 0) for the element with aspect-ratio when doing reflow for floats [1] because when we trying to put this element into the bottom-right available area, our flow available size is (0, 3000), so we use 0 as its available inline size in `nsIFrame::ComputeSize()`, and use 1/1 aspect-ratio, so the result is (0, 0). And then we stay in the do-while loop [1] forever. Still trying to figure why we don't break this loop and what is the expected behavior for this case.

[1] https://searchfox.org/mozilla-central/rev/5e15e00fa247cba5b765727496619bf9010ed162/layout/generic/nsBlockFrame.cpp#3858-3978
Revision 3 by
on 
My initial investigation for this bug:
`nsIFrame::ComputeSize()` (computed for `childReflowInput`) return (0, 0) for the element with aspect-ratio when doing reflow for floats [1] because when we trying to put this element into the bottom-right available area, our flow available size is (0, 3000), so we use 0 as its available inline size in `nsIFrame::ComputeSize()`, and use 1/1 aspect-ratio, so the result is (0, 0). And then we stay in the do-while loop [1] forever. Still trying to figure why we don't break this loop and what is the expected behavior for this case.

[1] https://searchfox.org/mozilla-central/rev/5e15e00fa247cba5b765727496619bf9010ed162/layout/generic/nsBlockFrame.cpp#3858-3978
Revision 4 by
on 
My initial investigation for this bug:
`nsIFrame::ComputeSize()` (computed for `childReflowInput`) return (0, 0) for the element with aspect-ratio when doing reflow [1] because when we trying to put this element into the bottom-right available area, our flow available size is (0, 3000), so we use 0 as its available inline size in `nsIFrame::ComputeSize()`, and use 1/1 aspect-ratio, so the result is (0, 0). And then we stay in the do-while loop [1] forever. Still trying to figure why we don't break this loop and what is the expected behavior for this case.

[1] https://searchfox.org/mozilla-central/rev/5e15e00fa247cba5b765727496619bf9010ed162/layout/generic/nsBlockFrame.cpp#3858-3978
Revision 5 by
on 
My initial investigation for this bug:
`nsIFrame::ComputeSize()` (called when we construct `childReflowInput`) return (0, 0) for the element with aspect-ratio when doing reflow [1] because when we trying to put this element into the bottom-right available area, our flow available size is (0, 3000), so we use 0 as its available inline size in `nsIFrame::ComputeSize()`, and use 1/1 aspect-ratio, so the result is (0, 0). And then we stay in the do-while loop [1] forever. Still trying to figure why we don't break this loop and what is the expected behavior for this case.

[1] https://searchfox.org/mozilla-central/rev/5e15e00fa247cba5b765727496619bf9010ed162/layout/generic/nsBlockFrame.cpp#3858-3978
Revision 6 by
on 
My initial investigation for this bug:
`nsIFrame::ComputeSize()` (called when we construct `childReflowInput`) return (0, 0) for the element with aspect-ratio when doing reflow [1]. When we try to put this element into the bottom-right available area, our flow available size is (0, 3000), so we use 0 as its available inline size in `nsIFrame::ComputeSize()`, and use 1/1 aspect-ratio, so the result is (0, 0). And then we stay in the do-while loop [1] forever. Still trying to figure why we don't break this loop and what is the expected behavior for this case.

[1] https://searchfox.org/mozilla-central/rev/5e15e00fa247cba5b765727496619bf9010ed162/layout/generic/nsBlockFrame.cpp#3858-3978
Revision 7 by
on 
My initial investigation for this bug:
`nsIFrame::ComputeSize()` (called when we construct `childReflowInput`) return (0, 0) for the element with aspect-ratio when doing reflow [1]. When we try to put this element into the bottom-right available area, our flow available size is (0, 3000), so we use 0 as its available inline size in `nsIFrame::ComputeSize()`, and use 1/1 aspect-ratio, so the result is (0, 0). And then we stay in the do-while loop [2] forever. Still trying to figure why we don't break this loop and what is the expected behavior for this case.

[1] https://searchfox.org/mozilla-central/rev/5e15e00fa247cba5b765727496619bf9010ed162/layout/generic/nsBlockFrame.cpp#3842-3844
[2] https://searchfox.org/mozilla-central/rev/5e15e00fa247cba5b765727496619bf9010ed162/layout/generic/nsBlockFrame.cpp#3858-3978

Back to Bug 1739260 Comment 3