Open Bug 1607709 Opened 4 years ago Updated 1 year ago

[mac] Scroll bar disappear on scrolling inside bookmarks and history menus (with permanent scroll bar turned on in system preferences)

Categories

(Core :: Web Painting, defect)

Unspecified
macOS
defect

Tracking

()

Tracking Status
firefox-esr68 --- fix-optional
firefox72 --- wontfix
firefox73 --- wontfix
firefox74 --- wontfix
firefox75 --- wontfix
firefox76 --- wontfix
firefox77 --- wontfix
firefox78 --- wontfix

People

(Reporter: cfogel, Unassigned)

References

(Regression)

Details

(Keywords: regression)

Attachments

(4 files)

Attached video dragbar.mov

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.
Attached image history_menu.png

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.

Flags: needinfo?(gijskruitbosch+bugs)
Priority: -- → P2

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?

Flags: needinfo?(cristian.fogel)

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

Updating flags for RC 72.0.1, 68.4.1esr as well.

Flags: needinfo?(cristian.fogel)
Regressed by: 1505582
Has Regression Range: --- → yes
Has STR: --- → yes

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...

Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(cristian.fogel)

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

It reproduces on all our available mac OS versions.

Flags: needinfo?(cristian.fogel)

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?

Summary: [mac] Scroll bar disappear on scrolling inside bookmarks and history menus → [mac] Scroll bar disappear on scrolling inside bookmarks and history menus (with permanent scroll bar turned on in system preferences)

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.

Flags: needinfo?(cristian.fogel)

Same result with the pref set to false.

Flags: needinfo?(cristian.fogel)

What's the next step here?

Flags: needinfo?(cam)

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

Flags: needinfo?(matt.woodrow)

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).

Flags: needinfo?(matt.woodrow)

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.

Flags: needinfo?(mikokm)

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

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

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.

Flags: needinfo?(mikokm)
Assignee: nobody → mikokm
Status: NEW → ASSIGNED
Attached file scrollbar-visible.txt
Attached file scrollbar-hidden.txt
Assignee: mikokm → nobody
Status: ASSIGNED → NEW
Assignee: nobody → mstange
Status: NEW → ASSIGNED
Severity: normal → S3

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

Flags: needinfo?(cam) → needinfo?(mstange)

I don't remember.

Assignee: mstange.moz → nobody
Status: ASSIGNED → NEW
Component: Layout: Scrolling and Overflow → Web Painting
Flags: needinfo?(mstange.moz)
Priority: P2 → --
You need to log in before you can comment on or make changes to this bug.