Affected versions

• 74.0a1(20200107215758), 73.0b2

Affected platforms

• mac OS 10.12, macOS 10.15

Steps to reproduce

1. Launch Firefox (have bookmarks/history on the profile - can be imported from other browsers);
2. Click on the View history, saved bookmarks and more button;
3. Click on either Bookmarks or History option from the dropdown menu;
4. Hover over the first menu option and scroll all the way down;

Expected result

• no glitches occur;

Actual result

• scroll bar is no longer fully displayed;

Regression range

• will look into it and provide one asap;

Additional notes

• attached recording with the issue;
• issue can be reproduced by grabbing and dragging the scroll bar as well.

Will wait on regression range but, Gijs do you have any thoughts? Has anything changed with this menu recently?

I notice when reproducing locally that the height of the list tends to get misaligned with the bottom of the scrollbar as well. It jumps back to the correct height on subsequent scroll events whenever a re-layout happens.

I can't think of anything that's changed in this department on the front-end side for a while now. Will keep needinfo to see if I can come up with something... Cristian, do you know if 72 / release and ESR are affected?

Using mozregression on macOS 10.13.6 managed to get the following pushlog:

• URL;
• most likely culprit seems to be bug 1505582.

Updating flags for RC 72.0.1, 68.4.1esr as well.

So does this not reproduce on 10.13 or 10.14 ? Only 10.12 and 10.15 ? That's... peculiar. Because the change in the regression window only changed the translucency of the background of the entire panel. I wouldn't have expected that to make any difference...

Ah, I can see your point. Might have been confusing with mentioning it as such.

It reproduces on all our available mac OS versions.

Seems this only reproduces with permanent scroll bars enabled.

I know very little about graphics/layout, but I can only imagine that the change to the background colour somehow made a difference in how layers etc. are computed and that's how that CSS change was able to trigger this bug?

Cristian, can you try with the layout.css.cached-scrollbar-styles.enabled pref set to false? That feature introduced a couple of regressions with scrollbar styling.

Same result with the pref set to false.

What's the next step here?

@Matt: Any thoughts on the theory in comment 6 that might lead us in the right direction?

Could reproduce the issue on Mac 10.14.6 with Firefox Nightly 75.0a1 (2020-02-13) with and without the pref from comment #7 set to false. Will add the according flag.

I can't reproduce this unfortunately.

It looks like it could be some sort of painting/sorting issue though, so next steps might be to collect a display list dump and see if the scrollbars are present or not (and in the right z order).

I can still reproduce this reliably in Nightly 76.

Miko: Might you be able to help diagnose (see comment 12)? Will get someone from layout to help as well.

(In reply to Cristian Fogel, QA [:cfogel] from comment #3)

Using mozregression on macOS 10.13.6 managed to get the following pushlog:

• URL;
• most likely culprit seems to be bug 1505582.

Updating flags for RC 72.0.1, 68.4.1esr as well.

I can confirm that this is the regressing patch. Backing it out locally fixes the issue. I am still investigating what the root cause is.

Hi Markus - Just curious if there's any update on this. Is this definitely an issue on the painting side of things?

I don't remember.