Affected versions

• 90.0a1 (20210525153449)
• 89.0 (20210524222230)

Affected platforms

• macOS 11
• Windows 10x64

Steps to reproduce

1. Open Firefox and add items to the overflow menu.
2. If the scrollbar is not displayed, resize the browser making it smaller until the scrollbar for the overflow is displayed.
3. Scroll down and observe the bottom area.

Expected result

• There is not a lot of space remaining.

Actual result

• A lot of empty space is displayed inside on the bottom area.

Regression range

• Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e17c6f92b2bf41e464bbbea1afbff9c9e78db93b&tochange=94323c03b3da46afb965744af83cb6acfa92fc63

Notes

• Attached a screenshot.

If I read the code correctly, the overflow menu is intended to have a large padding-bottom. https://searchfox.org/mozilla-central/rev/202250ee5931648185c8abb3061d738b15b64067/browser/themes/shared/customizableui/customizeMode.inc.css#551

Bug 1697349 makes the flex container add the padding-bottom to the scrollable overflow area. So in the "step to reproduce" in comment 0, if we scroll down to the bottom, the height of the padding-bottom should be the same as if the overflow menu has no scrollbars. (This can be observed when the browser height is enlarged again. The height of the padding-bottom should persist.)

Gijs, could you double check this is still the desired behavior of the UI even after bug 1697349? I'm leaning towards closing this as by design.

(In reply to Ting-Yu Lin [:TYLin] (UTC-7) from comment #1)

If I read the code correctly, the overflow menu is intended to have a large padding-bottom. https://searchfox.org/mozilla-central/rev/202250ee5931648185c8abb3061d738b15b64067/browser/themes/shared/customizableui/customizeMode.inc.css#551

Bug 1697349 makes the flex container add the padding-bottom to the scrollable overflow area. So in the "step to reproduce" in comment 0, if we scroll down to the bottom, the height of the padding-bottom should be the same as if the overflow menu has no scrollbars. (This can be observed when the browser height is enlarged again. The height of the padding-bottom should persist.)

Gijs, could you double check this is still the desired behavior of the UI even after bug 1697349? I'm leaning towards closing this as by design.

I think there shouldn't be a big space at the bottom of the scrollable list, it looks weird. When the CSS was written the padding wasn't applied to the scrollable list. What was the state before bug 1697349, if the list was so long and scrollable?

Here's screenshot before bug 1697349 of overflow menu with a long scrollable list (proton enabled). It looks nicer and I feel it's harder to drag-and-drop a new item to the bottom of the list.

Here's a simple testcase to help visualize the before/after behavior (if you load this testcase in release vs. Nightly and compare).

Basically, before bug 1697349, the padding contributed to the size of the scroll container, but it didn't introduce any additional scrollable area. After bug 1697349, it does both (contributes to the size of the container, and creates scrollable area). [And this is intentional & per-spec.]

If you don't want this behavior in this UI component, you probably want to remove the bottom padding here (and replace it with some corresponding amount of height or min-height perhaps).