When I was trying to always clamp the inline size between [0, nscoord_MAX], I got some more assertions in [try](https://treeherder.mozilla.org/jobs?repo=try&revision=55628fb75790f1996927be3d434d50c4a15e65c7&selectedTaskRun=TRh-VaMsQzCamCcy1CiNYg.0&searchStr=Linux%2C18.04%2Cx64%2Cdebug%2CReftests%2Ctest-linux1804-64%2Fdebug-crashtest-e10s%2CC): 1. __layout/generic/crashtests/323386-1.html__ (ASSERTION: computed inline size should always be computed: 'computedSize.ISize(wm) != NS_UNCONSTRAINEDSIZE', file /builds/worker/checkouts/gecko/layout/xul/nsBoxFrame.cpp:480) 2. __layout/generic/crashtests/first-letter-638937-2.html__ (ASSERTION: should no longer use unconstrained inline size: 'availSize.ISize(wm) != NS_UNCONSTRAINEDSIZE', file /builds/worker/checkouts/gecko/layout/generic/nsFirstLetterFrame.cpp:164) 3. __layout/base/crashtests/453894-1.xhtml__ (ASSERTION: FinishReflowChild with unconstrained container width!: 'aContainerSize.width != NS_UNCONSTRAINEDSIZE', file /builds/worker/checkouts/gecko/layout/generic/nsContainerFrame.cpp:1188) One of the reasons is that `ComputeAutoSize()` returns an inline size which is more than `nscoord_MAX` (e.g. 2147483646 in first-letter-638937-2.html because the margin is -2147483646), so my clamp makes it in the correct range and then hit the assertion. Perhaps we should always use something like `NSCoordSaturatingSubtract` to calculate: [`availBased`](https://searchfox.org/mozilla-central/rev/e75e8e5b980ef18f4596a783fbc8a36621de7d1e/layout/generic/nsContainerFrame.cpp#981-982): > `nscoord availBased = aAvailableISize - aMargin.ISize(aWM) - aBorderPadding.ISize(aWM);` However, the margin or the borderpadding may be an INT_MAX value, and this may hit another [assertion](https://searchfox.org/mozilla-central/rev/16d30bafd4e5276d6d3c632fb52a6c71e739cc44/gfx/src/nsCoord.h#203): > `MOZ_ASSERT_UNREACHABLE("Attempted to subtract [n - nscoord_MAX]");` We have to figure out what is the correct inline size that ComputeAutoSize() returns for these edge cases. Or just remove these assertions.
Bug 1675095 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
When I was trying to always [clamp the inline size](https://phabricator.services.mozilla.com/D94910) between [0, nscoord_MAX], I got some more assertions in [try](https://treeherder.mozilla.org/jobs?repo=try&revision=55628fb75790f1996927be3d434d50c4a15e65c7&selectedTaskRun=TRh-VaMsQzCamCcy1CiNYg.0&searchStr=Linux%2C18.04%2Cx64%2Cdebug%2CReftests%2Ctest-linux1804-64%2Fdebug-crashtest-e10s%2CC): 1. __layout/generic/crashtests/323386-1.html__ (ASSERTION: computed inline size should always be computed: 'computedSize.ISize(wm) != NS_UNCONSTRAINEDSIZE', file /builds/worker/checkouts/gecko/layout/xul/nsBoxFrame.cpp:480) 2. __layout/generic/crashtests/first-letter-638937-2.html__ (ASSERTION: should no longer use unconstrained inline size: 'availSize.ISize(wm) != NS_UNCONSTRAINEDSIZE', file /builds/worker/checkouts/gecko/layout/generic/nsFirstLetterFrame.cpp:164) 3. __layout/base/crashtests/453894-1.xhtml__ (ASSERTION: FinishReflowChild with unconstrained container width!: 'aContainerSize.width != NS_UNCONSTRAINEDSIZE', file /builds/worker/checkouts/gecko/layout/generic/nsContainerFrame.cpp:1188) One of the reasons is that `ComputeAutoSize()` returns an inline size which is more than `nscoord_MAX` (e.g. 2147483646 in first-letter-638937-2.html because the margin is -2147483646), so my clamp makes it in the correct range and then hit the assertion. Perhaps we should always use something like `NSCoordSaturatingSubtract` to calculate: [`availBased`](https://searchfox.org/mozilla-central/rev/e75e8e5b980ef18f4596a783fbc8a36621de7d1e/layout/generic/nsContainerFrame.cpp#981-982): > `nscoord availBased = aAvailableISize - aMargin.ISize(aWM) - aBorderPadding.ISize(aWM);` However, the margin or the borderpadding may be an INT_MAX value, and this may hit another [assertion](https://searchfox.org/mozilla-central/rev/16d30bafd4e5276d6d3c632fb52a6c71e739cc44/gfx/src/nsCoord.h#203): > `MOZ_ASSERT_UNREACHABLE("Attempted to subtract [n - nscoord_MAX]");` We have to figure out what is the correct inline size that ComputeAutoSize() returns for these edge cases. Or just remove these assertions.
When I was trying to always [clamp the inline size](https://phabricator.services.mozilla.com/D94910) between [0, nscoord_MAX], I got some more assertions in [try](https://treeherder.mozilla.org/jobs?repo=try&revision=55628fb75790f1996927be3d434d50c4a15e65c7&selectedTaskRun=TRh-VaMsQzCamCcy1CiNYg.0&searchStr=Linux%2C18.04%2Cx64%2Cdebug%2CReftests%2Ctest-linux1804-64%2Fdebug-crashtest-e10s%2CC): 1. **layout/generic/crashtests/323386-1.html** (_ASSERTION: computed inline size should always be computed: 'computedSize.ISize(wm) != NS_UNCONSTRAINEDSIZE', file [/builds/worker/checkouts/gecko/layout/xul/nsBoxFrame.cpp:480](https://searchfox.org/mozilla-central/rev/e75e8e5b980ef18f4596a783fbc8a36621de7d1e/layout/xul/nsBoxFrame.cpp#479-480)_) 2. **layout/generic/crashtests/first-letter-638937-2.html** (_ASSERTION: should no longer use unconstrained inline size: 'availSize.ISize(wm) != NS_UNCONSTRAINEDSIZE', file [/builds/worker/checkouts/gecko/layout/generic/nsFirstLetterFrame.cpp:164](https://searchfox.org/mozilla-central/rev/e75e8e5b980ef18f4596a783fbc8a36621de7d1e/layout/generic/nsFirstLetterFrame.cpp#163-164)_) 3. **layout/base/crashtests/453894-1.xhtml** (_ASSERTION: FinishReflowChild with unconstrained container width!: 'aContainerSize.width != NS_UNCONSTRAINEDSIZE', file [/builds/worker/checkouts/gecko/layout/generic/nsContainerFrame.cpp:1188](https://searchfox.org/mozilla-central/rev/e75e8e5b980ef18f4596a783fbc8a36621de7d1e/layout/generic/nsContainerFrame.cpp#1187-1188)_) One of the reasons is that `ComputeAutoSize()` returns an inline size which is more than `nscoord_MAX` (e.g. 2147483646 in first-letter-638937-2.html because the margin is -2147483646), so my clamp makes it in the correct range and then hit the assertion. Perhaps we should always use something like `NSCoordSaturatingSubtract` to calculate: [`availBased`](https://searchfox.org/mozilla-central/rev/e75e8e5b980ef18f4596a783fbc8a36621de7d1e/layout/generic/nsContainerFrame.cpp#981-982): > `nscoord availBased = aAvailableISize - aMargin.ISize(aWM) - aBorderPadding.ISize(aWM);` However, the margin or the borderpadding may be an INT_MAX value, and this may hit another [assertion](https://searchfox.org/mozilla-central/rev/16d30bafd4e5276d6d3c632fb52a6c71e739cc44/gfx/src/nsCoord.h#203): > `MOZ_ASSERT_UNREACHABLE("Attempted to subtract [n - nscoord_MAX]");` We have to figure out what is the correct inline size that ComputeAutoSize() returns for these edge cases. Or just remove these assertions.
When I was trying to always [clamp the inline size](https://phabricator.services.mozilla.com/D94910) between [0, nscoord_MAX], I got some more assertions in [try](https://treeherder.mozilla.org/jobs?repo=try&revision=55628fb75790f1996927be3d434d50c4a15e65c7&selectedTaskRun=TRh-VaMsQzCamCcy1CiNYg.0&searchStr=Linux%2C18.04%2Cx64%2Cdebug%2CReftests%2Ctest-linux1804-64%2Fdebug-crashtest-e10s%2CC): 1. **layout/generic/crashtests/first-letter-638937-2.html** (_ASSERTION: should no longer use unconstrained inline size: 'availSize.ISize(wm) != NS_UNCONSTRAINEDSIZE', file [/builds/worker/checkouts/gecko/layout/generic/nsFirstLetterFrame.cpp:164](https://searchfox.org/mozilla-central/rev/e75e8e5b980ef18f4596a783fbc8a36621de7d1e/layout/generic/nsFirstLetterFrame.cpp#163-164)_) 2. **layout/generic/crashtests/323386-1.html** (_ASSERTION: computed inline size should always be computed: 'computedSize.ISize(wm) != NS_UNCONSTRAINEDSIZE', file [/builds/worker/checkouts/gecko/layout/xul/nsBoxFrame.cpp:480](https://searchfox.org/mozilla-central/rev/e75e8e5b980ef18f4596a783fbc8a36621de7d1e/layout/xul/nsBoxFrame.cpp#479-480)_) 3. **layout/base/crashtests/453894-1.xhtml** (_ASSERTION: FinishReflowChild with unconstrained container width!: 'aContainerSize.width != NS_UNCONSTRAINEDSIZE', file [/builds/worker/checkouts/gecko/layout/generic/nsContainerFrame.cpp:1188](https://searchfox.org/mozilla-central/rev/e75e8e5b980ef18f4596a783fbc8a36621de7d1e/layout/generic/nsContainerFrame.cpp#1187-1188)_) One of the reasons is that `ComputeAutoSize()` returns an inline size which is more than `nscoord_MAX` (e.g. 2147483646 in first-letter-638937-2.html because the margin is -2147483646), so my clamp makes it in the correct range and then hit the assertion. Perhaps we should always use something like `NSCoordSaturatingSubtract` to calculate: [`availBased`](https://searchfox.org/mozilla-central/rev/e75e8e5b980ef18f4596a783fbc8a36621de7d1e/layout/generic/nsContainerFrame.cpp#981-982): > `nscoord availBased = aAvailableISize - aMargin.ISize(aWM) - aBorderPadding.ISize(aWM);` However, the margin or the borderpadding may be an INT_MAX value, and this may hit another [assertion](https://searchfox.org/mozilla-central/rev/16d30bafd4e5276d6d3c632fb52a6c71e739cc44/gfx/src/nsCoord.h#203): > `MOZ_ASSERT_UNREACHABLE("Attempted to subtract [n - nscoord_MAX]");` We have to figure out what is the correct inline size that ComputeAutoSize() returns for these edge cases. Or just remove these assertions.
When I was trying to always [clamp the inline size](https://phabricator.services.mozilla.com/D94910) between [0, nscoord_MAX], I got some more assertions in [try](https://treeherder.mozilla.org/jobs?repo=try&revision=55628fb75790f1996927be3d434d50c4a15e65c7&selectedTaskRun=TRh-VaMsQzCamCcy1CiNYg.0&searchStr=Linux%2C18.04%2Cx64%2Cdebug%2CReftests%2Ctest-linux1804-64%2Fdebug-crashtest-e10s%2CC): 1. **layout/generic/crashtests/first-letter-638937-2.html** (_ASSERTION: should no longer use unconstrained inline size: 'availSize.ISize(wm) != NS_UNCONSTRAINEDSIZE', file [/builds/worker/checkouts/gecko/layout/generic/nsFirstLetterFrame.cpp:164](https://searchfox.org/mozilla-central/rev/e75e8e5b980ef18f4596a783fbc8a36621de7d1e/layout/generic/nsFirstLetterFrame.cpp#163-164)_) 2. **layout/generic/crashtests/323386-1.html** (_ASSERTION: computed inline size should always be computed: 'computedSize.ISize(wm) != NS_UNCONSTRAINEDSIZE', file [/builds/worker/checkouts/gecko/layout/xul/nsBoxFrame.cpp:480](https://searchfox.org/mozilla-central/rev/e75e8e5b980ef18f4596a783fbc8a36621de7d1e/layout/xul/nsBoxFrame.cpp#479-480)_) 3. **layout/base/crashtests/453894-1.xhtml** (_ASSERTION: FinishReflowChild with unconstrained container width!: 'aContainerSize.width != NS_UNCONSTRAINEDSIZE', file [/builds/worker/checkouts/gecko/layout/generic/nsContainerFrame.cpp:1188](https://searchfox.org/mozilla-central/rev/e75e8e5b980ef18f4596a783fbc8a36621de7d1e/layout/generic/nsContainerFrame.cpp#1187-1188)_) One of the reasons is that `ComputeAutoSize()` returns an inline size which is more than `nscoord_MAX` (e.g. 2147483646 in first-letter-638937-2.html because the margin is -2147483646), so my clamp makes it in the correct range and then hit the assertion. Perhaps we should always use something like `NSCoordSaturatingSubtract` to calculate: [`availBased`](https://searchfox.org/mozilla-central/rev/e75e8e5b980ef18f4596a783fbc8a36621de7d1e/layout/generic/nsContainerFrame.cpp#981-982): `nscoord availBased = aAvailableISize - aMargin.ISize(aWM) - aBorderPadding.ISize(aWM);` However, the margin or the borderpadding may be an INT_MAX value, and this may hit another [assertion](https://searchfox.org/mozilla-central/rev/16d30bafd4e5276d6d3c632fb52a6c71e739cc44/gfx/src/nsCoord.h#203): `MOZ_ASSERT_UNREACHABLE("Attempted to subtract [n - nscoord_MAX]");` We have to figure out what is the correct inline size that ComputeAutoSize() returns for these edge cases. Or just remove these assertions.
When I was trying to always [clamp the inline size](https://phabricator.services.mozilla.com/D94910) between [0, nscoord_MAX], I got some more assertions in [try](https://treeherder.mozilla.org/jobs?repo=try&revision=55628fb75790f1996927be3d434d50c4a15e65c7&selectedTaskRun=TRh-VaMsQzCamCcy1CiNYg.0&searchStr=Linux%2C18.04%2Cx64%2Cdebug%2CReftests%2Ctest-linux1804-64%2Fdebug-crashtest-e10s%2CC): 1. **layout/generic/crashtests/first-letter-638937-2.html** (_ASSERTION: should no longer use unconstrained inline size: 'availSize.ISize(wm) != NS_UNCONSTRAINEDSIZE', file [/builds/worker/checkouts/gecko/layout/generic/nsFirstLetterFrame.cpp:164](https://searchfox.org/mozilla-central/rev/e75e8e5b980ef18f4596a783fbc8a36621de7d1e/layout/generic/nsFirstLetterFrame.cpp#163-164)_) 2. **layout/generic/crashtests/323386-1.html** (_ASSERTION: computed inline size should always be computed: 'computedSize.ISize(wm) != NS_UNCONSTRAINEDSIZE', file [/builds/worker/checkouts/gecko/layout/xul/nsBoxFrame.cpp:480](https://searchfox.org/mozilla-central/rev/e75e8e5b980ef18f4596a783fbc8a36621de7d1e/layout/xul/nsBoxFrame.cpp#479-480)_) 3. **layout/base/crashtests/453894-1.xhtml** (_ASSERTION: FinishReflowChild with unconstrained container width!: 'aContainerSize.width != NS_UNCONSTRAINEDSIZE', file [/builds/worker/checkouts/gecko/layout/generic/nsContainerFrame.cpp:1188](https://searchfox.org/mozilla-central/rev/e75e8e5b980ef18f4596a783fbc8a36621de7d1e/layout/generic/nsContainerFrame.cpp#1187-1188)_) One of the reasons is that `ComputeAutoSize()` returns an inline size which is more than `nscoord_MAX` (e.g. 2147483646 in first-letter-638937-2.html because the margin is -2147483646), so my clamp makes it in the correct range and then hit the assertion. Perhaps we should always use something like `NSCoordSaturatingSubtract` to calculate [`availBased`](https://searchfox.org/mozilla-central/rev/e75e8e5b980ef18f4596a783fbc8a36621de7d1e/layout/generic/nsContainerFrame.cpp#981-982): `nscoord availBased = aAvailableISize - aMargin.ISize(aWM) - aBorderPadding.ISize(aWM);` However, the margin or the borderpadding may be an INT_MAX value, and this may hit another [assertion](https://searchfox.org/mozilla-central/rev/16d30bafd4e5276d6d3c632fb52a6c71e739cc44/gfx/src/nsCoord.h#203): `MOZ_ASSERT_UNREACHABLE("Attempted to subtract [n - nscoord_MAX]");` We have to figure out what is the correct inline size that ComputeAutoSize() returns for these edge cases. Or just remove these assertions.
When I was trying to always [clamp the inline size](https://phabricator.services.mozilla.com/D94910) between [0, nscoord_MAX], I got some more assertions in [try](https://treeherder.mozilla.org/jobs?repo=try&revision=55628fb75790f1996927be3d434d50c4a15e65c7&selectedTaskRun=TRh-VaMsQzCamCcy1CiNYg.0&searchStr=Linux%2C18.04%2Cx64%2Cdebug%2CReftests%2Ctest-linux1804-64%2Fdebug-crashtest-e10s%2CC): 1. **layout/generic/crashtests/first-letter-638937-2.html** (_ASSERTION: should no longer use unconstrained inline size: 'availSize.ISize(wm) != NS_UNCONSTRAINEDSIZE', file [/builds/worker/checkouts/gecko/layout/generic/nsFirstLetterFrame.cpp:164](https://searchfox.org/mozilla-central/rev/e75e8e5b980ef18f4596a783fbc8a36621de7d1e/layout/generic/nsFirstLetterFrame.cpp#163-164)_) 2. **layout/generic/crashtests/323386-1.html** (_ASSERTION: computed inline size should always be computed: 'computedSize.ISize(wm) != NS_UNCONSTRAINEDSIZE', file [/builds/worker/checkouts/gecko/layout/xul/nsBoxFrame.cpp:480](https://searchfox.org/mozilla-central/rev/e75e8e5b980ef18f4596a783fbc8a36621de7d1e/layout/xul/nsBoxFrame.cpp#479-480)_) 3. **layout/base/crashtests/453894-1.xhtml** (_ASSERTION: FinishReflowChild with unconstrained container width!: 'aContainerSize.width != NS_UNCONSTRAINEDSIZE', file [/builds/worker/checkouts/gecko/layout/generic/nsContainerFrame.cpp:1188](https://searchfox.org/mozilla-central/rev/e75e8e5b980ef18f4596a783fbc8a36621de7d1e/layout/generic/nsContainerFrame.cpp#1187-1188)_) One of the reasons is that `ComputeAutoSize()` returns an inline size which is more than `nscoord_MAX` (e.g. 2147483646 in first-letter-638937-2.html because the margin is -2147483646), so my clamp makes it in the correct range and then I hit the assertion. Perhaps we should always use something like `NSCoordSaturatingSubtract` to calculate [`availBased`](https://searchfox.org/mozilla-central/rev/e75e8e5b980ef18f4596a783fbc8a36621de7d1e/layout/generic/nsContainerFrame.cpp#981-982): `nscoord availBased = aAvailableISize - aMargin.ISize(aWM) - aBorderPadding.ISize(aWM);` However, the margin or the borderpadding may be an INT_MAX value, and this may hit another [assertion](https://searchfox.org/mozilla-central/rev/16d30bafd4e5276d6d3c632fb52a6c71e739cc44/gfx/src/nsCoord.h#203): `MOZ_ASSERT_UNREACHABLE("Attempted to subtract [n - nscoord_MAX]");` We have to figure out what is the correct inline size that ComputeAutoSize() returns for these edge cases. Or just remove these assertions.