STR: 0. Have a mouse with a scrollwheel. 1. Trigger about:sessionrestore with a bunch of tabs to be restored. (e.g. by crashing via bug 1125304 comment 2, and then restarting firefox.) (This doesn't reliably trigger about about:sessionrestore for me, in a near-fresh profile, for some reason -- so I can't provide exact STR, but it was doing so earlier today in my main browing profile.) 2. Try to scroll through the list of tabs to be restored, using your mousewheel, in small increments. EXPECTED RESULTS: One mousewheel tick should scroll one line (or smooth-scroll several lines). ACTUAL RESULTS: One mousewheel tick scrolles many lines, in one large "jump", so it's really hard to visually follow where you ended up after scrolling a tick.

(In reply to Daniel Holbert [:dholbert] from comment #0) > (This doesn't reliably trigger about about:sessionrestore for me, in a > near-fresh profile, for some reason -- so I can't provide exact STR, but it > was doing so earlier today in my main browing profile.) (Ah -- I had better luck getting a working "about:sessionrestore" page after I set browser.sessionstore.max_resumed_crashes to 0. Then, I got about:sessionrestore immediately after crashing. Noting here in case it's helpful for others.)

Here's a screencast of this bug. I start out by using my scrollwheel (doing only a single "tick" of scrolling -- the smallest amount I can do). As shown in the screencast, that seems to scroll by 3 lines, which is practically an entire widget-full of lines. (The "TBPL" tab snaps from the bottom to near the top.) (Later on in the screencast, I use the arrow-buttons on the scrollbar -- these do scroll by one line at a time, as you'd expect. So, those aren't broken.) This bug is pretty bad -- the whole point of this UI is to let you rapidly scan through your tabs to find ones that you recently opened and/or which you suspect as having caused your previous crash. But with this bug jarring you out of context every time you scroll, it's pretty hard to actually do that & read the tab-titles as you scroll through them. :-(

I actually realized the behavior is the same (3 lines are scrolled per scrollwheel tick) in old builds, but it's less jarring there because the pane is larger (it grows with your window-size) whereas the pane is a very small fixed size in the new UI. Here's a screencast of a build from a few days ago, before the UI refresh.

So I guess this bug itself (the large amount of scrolling) is not a regression, but I think it's still worth tracking. --> Clarifying bug summary. I'll file a separate bug on the new scroll UI not resizing to fit your window, which is really the regression that caused me trouble here (and made this particularly jarring).

(I filed bug 1125952 on the tabs-to-restore listing being too small & not responsive to window-size in the new UI, FWIW.)

(In reply to Daniel Holbert [:dholbert] from comment #0) > EXPECTED RESULTS: > One mousewheel tick should scroll one line (or smooth-scroll several lines). Revising this slightly: for consistency with other scrollable things (like <textarea> and iframes), we should should *smooth-scroll* several lines here. (So the problem isn't that we're scrolling too much -- it's that we're scrolling abruptly instead of smoothly. This makes it impossible to visually track the scrolled region.)

Does this happen in other XUL trees, like in about:preferences ? If this is specific to session restore, it should probably be in Firefox :: Session Restore; if it happens to all XUL trees, it probably needs to go into Core :: XUL.

(In reply to :Gijs Kruitbosch from comment #7) > Does this happen in other XUL trees, like in about:preferences ? Good question. It does indeed happen for "about:config" (which is a giant XUL tree). So, this is not sessionrestore-specific. Reclassifying to Core|XUL, as you suggest.