STR:

1. Open Firefox View.
2. Click the show/hide button to the right of "recently closed" (which initially looks like a ^)

ACTUAL RESULTS:
The button jumps out from under your mouse, and in fact the whole section (including the title) jumps downwards to a new position, for no obvious reason/benefit.

EXPECTED RESULT:

• Buttons shouldn't move when you click them.
• This section shouldn't change positions when it's opened/collapsed.

Here's a screencast showing this issue.

(Unfortunately my screencasting program doesn't capture my cursor, so you'll have to imagine where I'm pointing; but you can clearly see the button jumping up and down.)

Also worth noting: the same button on the "Tab Pickup" section at the top is just fine, as shown at the end of my video. It doesn't jump at all when clicked. But the one on the "Recently Closed" section is quite jumpy.

It looks like this is something to do with the grid layout that we're using to define the heights here. We're not explicitly declaring grid-template-rows, so their heights are just content-based.

And as part of that, the rows each absorb proportional-to-their-content amounts of the multi-row-spanning Colorways Aside section on the right when it becomes taller than the rest of the content (as it does when you collapse the "recently closed" section).

Here's a screencast showing that this only happens when the Colorways <aside> is present. If I explicitly prevent that element from influencing layout by giving it with display:none (at t=10s in this screencast), then the bug goes away.

So: this has to do with that <aside> element influencing the size of the grid rows when it's the tallest thing (which it is when Recently Closed section is collapsed), in a way that we would like to avoid so as to keep the button from unexpectedly jumping out from under the user's cursor.

I think this is fundamentally the same issue as bug 1785868, though it's worth keeping it separate for now so we don't end up fixing one without the other. Masonry layout resolves both issues but isn't available on beta or release so is no help to us. We haven't been able to find a grid fix that resolves the alignment of both items when collapsed.

I think I've found a grid solution for this without using masonry, but I'll add you as a reviewer, Gijs. It should also resolve bug 1785868.

Looks like Hanna already added a fix for this here: https://phabricator.services.mozilla.com/D156880, so let me know if I should just abandon my revision.

(In reply to Kelly Cochrane [:kcochrane] from comment #8)

Looks like Hannah already added a fix for this here: https://phabricator.services.mozilla.com/D156880, so let me know if I should just abandon my revision.

I think the updated solution here is an additional improvement, so let's rebase this on top of current autoland and get it landed. Thanks, Kelly!

It looks like as I'm signing on for the day that Hanna's patch already made it to central, so I've rebased my patch from latest central.

https://hg.mozilla.org/mozilla-central/rev/dd286ef37a52

Hello,

Managed to reproduce this issue on 106.0a1 (20220905214329) using macOS 12.

Confirming this issue as verified fixed on 106.0b2(20220920185943) and Nightly 107.0a1(20220920092542) using macOS 12, Windows 11 and Ubuntu 22.