Bug 1940367 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.

IanK alerted me to some pieces of this test (added in bug 1937624) that are failing in Chrome, probably for incorrect reasons:
https://wpt.live/css/css-sizing/stretch/stretch-block-size-003.html

I think the same is true for this test:
https://wpt.live/css/css-sizing/stretch/stretch-inline-size-003.html

Each piece of those tests has an abspos element whose in-flow parent is distinct from its abspos containing block. The trouble arises from cases where the in-flow parent is 0x0 due to writing-mode differences between it and its parent; this creates a situation where `stretch` should trivially resolve to 0, which isn't too interesting.  (The test expects it to resolve to something nonzero right now, but that's because it's depending on a Firefox bug -- bug 1940321, I think.)

Let's rescue the tests so that none of these elements are inadvertently 0x0, so that `stretch` can reliably actually stretch to a nonzero size on the abspos child.
IanK alerted me to some pieces of this test (added in bug 1937624) that are failing in Chrome, where the test's expectations are probably incorrect:
https://wpt.live/css/css-sizing/stretch/stretch-block-size-003.html

I think the same is true for this test:
https://wpt.live/css/css-sizing/stretch/stretch-inline-size-003.html

Each piece of those tests has an abspos element whose in-flow parent is distinct from its abspos containing block. The trouble arises from cases where the in-flow parent is 0x0 due to writing-mode differences between it and its parent; this creates a situation where `stretch` should trivially resolve to 0, which isn't too interesting.  (The test expects it to resolve to something nonzero right now, but that's because it's depending on a Firefox bug -- bug 1940321, I think.)

Let's rescue the tests so that none of these elements are inadvertently 0x0, so that `stretch` can reliably actually stretch to a nonzero size on the abspos child.
IanK alerted me to some pieces of this test (added in bug 1937624) that are failing in Chrome, where the test's expectations are probably incorrect:
https://wpt.live/css/css-sizing/stretch/stretch-block-size-003.html

I think the same is true for this test:
https://wpt.live/css/css-sizing/stretch/stretch-inline-size-003.html

Each piece of those tests has an abspos element whose in-flow parent is distinct from its abspos containing block. The trouble arises from cases where the in-flow parent is 0x0 due to writing-mode differences between it and its parent; this creates a situation where `stretch` should trivially resolve to 0, which isn't too interesting.  (The test expects it to resolve to something nonzero right now, but that's because it's accidentally depending on a Firefox bug -- bug 1940321, I think -- which is how we manage to pass the test right now.)

Let's rescue the tests so that none of these elements are inadvertently 0x0, so that `stretch` can reliably actually stretch to a nonzero size on the abspos child.
IanK alerted me to some pieces of this test (added in bug 1937624) that are failing in Chrome, where the test's expectations are probably incorrect:
https://wpt.live/css/css-sizing/stretch/stretch-block-size-003.html

I think the same is true for this test:
https://wpt.live/css/css-sizing/stretch/stretch-inline-size-003.html

Each piece of those tests has an abspos element whose in-flow parent is distinct from its abspos containing block. The trouble arises from cases where the in-flow parent is 0x0 due to writing-mode differences between it and its parent; this creates a situation where `stretch` should trivially resolve to 0, which isn't too interesting.  (The test expects it to resolve to something nonzero right now, but that's because it's accidentally depending on a Firefox bug -- bug 1940321, I think -- which is how we manage to pass the test right now, with its incorrect expectations.)

Let's rescue these two tests so that none of these elements are inadvertently 0x0, so that `stretch` can reliably actually stretch to a nonzero size on the abspos child.

Back to Bug 1940367 Comment 0