Bug 483403 added a workaround that disabled smooth scrolling during session restore. Dão, do you remember why this was introduced, was it just to make the selected tab immediately visible? Is this code still needed, and if so do you know if this can be done in other ways? Or Mike? I'm looking at the arrowscollbox binding and, apart from test code, this seems to be the only place where we change the smooth scrolling mode at runtime.

(In reply to :Paolo Amadini from comment #0) > Bug 483403 added a workaround that disabled smooth scrolling during session > restore. > > Dão, do you remember why this was introduced, was it just to make the > selected tab immediately visible? Is this code still needed, and if so do > you know if this can be done in other ways? Or Mike? It's still needed. When restoring a window, we don't want to animate scrolling to the selected tab as this is both distracting and expensive. > I'm looking at the arrowscollbox binding and, apart from test code, this > seems to be the only place where we change the smooth scrolling mode at > runtime. Why is this a problem?

There are several XBL bindings that control scrolling, mainly for historical reasons, and we are looking into flattening the inheritance in preparation for a conversion to Custom Elements. I'm now looking into which common features are required. The current approach here of exposing a smoothScroll property may still work, but another possibility is to expose a method parameter to scroll instantly, or even use the underlying CSS frame scrolling methods. Moving the bug to XUL Widgets since this is more of an investigation driven by the work we're doing there, rather than something we have to fix in Session Restore.