Bugzilla

So, I have one concern with the approach here -- sort of theoretical, but I suspect a testcase could be constructed that would demonstrate it...

* Suppose we're doing a reflow where the flex item's content-box size changes, in a way that we currently rely on this cache to detect. Let's say it gets 10px taller.
* Now, suppose it simultaneously loses 10px of vertical padding (due to its padding being percent-valued and its percent basis changing.
* So: its padding-box (and border-box) would remain the same size.

In this scenario, current mozilla-central would detect this and would reflow the flex item to account for the content-box size change. But this patch-stack (part 4 in particular) would prevent us from detecting that the flex item needs a new final reflow; we wouldn't see that its content-box changed size, and we'd skip the final reflow.

To avoid this problem, I suspect we may need to come at this a different way... :-/  One option would be to store the padding (or BorderPadding) as its own `LogicalMargin` member-var in the cached metrics, and compare it / reset it / etc. as part of our regular cache usage.

With that approach, the flex-item-size that we're also storing could still be the content-box size, or it could be the border-box size -- whatever feels more ergonomic, I think.  Regardless of which size we store: in my pathological scenario that I described above, we would now be able to detect that the cache was invalid and we need to reflow, because we'd see that the padding (or BorderPadding) has changed.

So, I have one concern with the approach here -- sort of theoretical, but I suspect a testcase could be constructed that would demonstrate it...

* Suppose we're doing a reflow where the flex item's content-box size changes, in a way that we currently rely on this cache to detect. Let's say it gets 10px taller.
* Now, suppose it simultaneously loses 10px of vertical padding (due to its padding being percent-valued and its percent basis changing.
* So: its padding-box (and border-box) would remain the same size.

In this scenario, current mozilla-central would detect this and would reflow the flex item to account for the content-box size change. But this patch-stack (part 4 in particular) would prevent us from detecting that the flex item needs a new final reflow; we wouldn't see that its content-box changed size, and we'd skip the final reflow.

To avoid this problem, I suspect we ~may need to come at this a different way...~ (EDIT: or rather, we might just need one additional hack...)  One option would be to store the padding (or BorderPadding) as its own `LogicalMargin` member-var in the cached metrics, and compare it / reset it / etc. as part of our regular cache usage.

With that approach, the flex-item-size that we're also storing could still be the content-box size, or it could be the border-box size -- whatever feels more ergonomic, I think.  Regardless of which size we store: in my pathological scenario that I described above, we would now be able to detect that the cache was invalid and we need to reflow, because we'd see that the padding (or BorderPadding) has changed.

So, I have one concern with the approach here -- sort of theoretical, but I suspect a testcase could be constructed that would demonstrate it...

* Suppose we're doing a reflow where the flex item's content-box size changes, in a way that we currently rely on this cache to detect. Let's say it gets 10px taller.
* Now, suppose it simultaneously loses 10px of vertical padding (due to its padding being percent-valued and its percent basis changing.
* So: its padding-box (and border-box) would remain the same size.

In this scenario, current mozilla-central would detect this and would reflow the flex item to account for the content-box size change. But this patch-stack (part 4 in particular) would prevent us from detecting that the flex item needs a new final reflow; we wouldn't see that its content-box changed size, and we'd skip the final reflow.

To avoid this problem, I suspect we ~may need to come at this a different way...~ (EDIT: perhaps more-correctly: we might just need one additional hack...)  One option would be to store the padding (or BorderPadding) as its own `LogicalMargin` member-var in the cached metrics, and compare it / reset it / etc. as part of our regular cache usage.

With that approach, the flex-item-size that we're also storing could still be the content-box size, or it could be the border-box size -- whatever feels more ergonomic, I think.  Regardless of which size we store: in my pathological scenario that I described above, we would now be able to detect that the cache was invalid and we need to reflow, because we'd see that the padding (or BorderPadding) has changed.