Bug 1610597 Comment 23 Edit History

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

(In reply to Tim Nguyen :ntim from comment #8)
> It's a non-zero effort to also land the stack frame removal backout on Nightly, but I could potentially reconsider it later on if needed.

ntim, would you mind landing this <stack>-frame removal-backout on Nightly, so that we can use `<legacy-stack>` here & in related bugs for the time being?

The testcases on bug 1614447 show that intrinsic sizing is pretty broken in both axes for stack-emulated-via-grid right now.  (Particularly from the perspective of the stack's parent box, which probes the stack for its preferred size as an input to the parent-box's XUL layout.) It's possible we can fix it, but I'm unsure about how straightforward it'll be & how robust the fix will be, given that sizing/reflow happen at different times in XUL layout vs. our modern layout codepaths, and the sizes that we need here ("early" in the XUL algorithm, for the parent-box's XUL layout) are the results from information that we calculate "late" in the modern reflow codepath.  Also: even if we come up with a fix, there may be other cases where we need to revert to the <legacy-stack> behavior to stave off some UI bustage that we don't have the resources to investigate/fix immediately.

So I'd like to have the <legacy-stack> codepath available to us for the time being, so we can mitigate this bug and the associated bugs without being gated on XUL reflow rr-debugging & hacks.
(In reply to Tim Nguyen :ntim from comment #8)
> It's a non-zero effort to also land the stack frame removal backout on Nightly, but I could potentially reconsider it later on if needed.

ntim, would you mind landing this <stack>-frame removal-backout on Nightly, so that we can use <legacy-stack> here & in related bugs for the time being?

The testcases on bug 1614447 show that intrinsic sizing is pretty broken in both axes for stack-emulated-via-grid right now.  (Particularly from the perspective of the stack's parent box, which probes the stack for its preferred size as an input to the parent-box's XUL layout.) It's possible we can fix it, but I'm unsure about how straightforward it'll be & how robust the fix will be, given that sizing/reflow happen at different times in XUL layout vs. our modern layout codepaths, and the sizes that we need here ("early" in the XUL algorithm, for the parent-box's XUL layout) are the results from information that we calculate "late" in the modern reflow codepath.  Also: even if we come up with a fix, there may be other cases where we need to revert to the <legacy-stack> behavior to stave off some UI bustage that we don't have the resources to investigate/fix immediately.

So I'd like to have the <legacy-stack> codepath available to us for the time being, so we can mitigate this bug and the associated bugs without being gated on XUL reflow rr-debugging & hacks.

Back to Bug 1610597 Comment 23