There are two bugs here. ContentView's are never restoring their scroll positions from BackFrowardEntry as expected because a new BackFrowardEntry is created each time. Second, many ContentViews don't implement scrollableElements.
<rdar://problem/26286090>
Created attachment 278941 [details] Patch
Comment on attachment 278941 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=278941&action=review r=me > Source/WebInspectorUI/UserInterface/Views/ContentViewContainer.js:96 > + // is undefined, so we want to show with a state last used. Initially I was worried this could reuse scroll positions where it's not appropriate. For example, two timeline recordings are made, and switching between recordings would reuse the last scroll positions. I'm not sure this will be a problem though, since we create new ContentViews for each representedObject instance. Or, at least, that's what we should be doing. There may be some places that still use singletons (i.e., storage views) where this may have undesirable behavior.
Comment on attachment 278941 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=278941&action=review >> Source/WebInspectorUI/UserInterface/Views/ContentViewContainer.js:96 >> + // is undefined, so we want to show with a state last used. > > Initially I was worried this could reuse scroll positions where it's not appropriate. For example, two timeline recordings are made, and switching between recordings would reuse the last scroll positions. > > I'm not sure this will be a problem though, since we create new ContentViews for each representedObject instance. Or, at least, that's what we should be doing. There may be some places that still use singletons (i.e., storage views) where this may have undesirable behavior. Yes, we have different views in that case.
https://trac.webkit.org/r200947