Bugzilla

(copying from the see also bug for visibility as that bug hasn't moved much and has no performance profiles - would be interesting to see those from other folks if they are also experiencing this to see if the root cause is the same)

Some quick notes while I continue to be on sick leave (gotta amuse myself somehow):

- I think the only thing the scrollbox is trying to do is make sure that at the end of a wheel scroll the scrolled area aligns with the start/ends of tabs. ISTM that in 2024, that may be better accomplished by CSS scroll snapping? It's unclear to me off-hand how easy it is to replace all the logic in the scrollbox with that, but it seems worth investigating. I also don't know if it'd fix this issue entirely
- like comment 23 I wonder if we need to coalesce wheel events - ISTM there are, like, an absolute tonne coming from the scrollwheel in the profile (multiple events per few ms) and making that fast and smooth is always gonna be tricky. The budget for processing these events doesn't appear to be 16ms as you'd expect at 60fps but more like... less than 1ms.
- it's not clear to me from the profile off-hand if the scrolling happens in an expanded or collapsed vertical tabstrip. There's a separate bug on file (that I can't find real quick off-hand) that discusses that we `display: none`/non-none the close button on hover for the vertical tabstrip as well, and that means more complex re-layout stuff happens. It may be that addressing that would further help with the style/layout/paint cycles here, though I still think the previous point may be more impactful.

(copying in some folks from the see also bug for visibility as that bug hasn't moved much and has no performance profiles - would be interesting to see those from other folks if they are also experiencing this to see if the root cause is the same)

Some quick notes while I continue to be on sick leave (gotta amuse myself somehow):

- I think the only thing the scrollbox is trying to do is make sure that at the end of a wheel scroll the scrolled area aligns with the start/ends of tabs. ISTM that in 2024, that may be better accomplished by CSS scroll snapping? It's unclear to me off-hand how easy it is to replace all the logic in the scrollbox with that, but it seems worth investigating. I also don't know if it'd fix this issue entirely
- like comment 23 I wonder if we need to coalesce wheel events - ISTM there are, like, an absolute tonne coming from the scrollwheel in the profile (multiple events per few ms) and making that fast and smooth is always gonna be tricky. The budget for processing these events doesn't appear to be 16ms as you'd expect at 60fps but more like... less than 1ms.
- it's not clear to me from the profile off-hand if the scrolling happens in an expanded or collapsed vertical tabstrip. There's a separate bug on file (that I can't find real quick off-hand) that discusses that we `display: none`/non-none the close button on hover for the vertical tabstrip as well, and that means more complex re-layout stuff happens. It may be that addressing that would further help with the style/layout/paint cycles here, though I still think the previous point may be more impactful.