When viewing the Timelines view for "JavaScript & Events", and pressing the right arrow on a particular function name, we're taken to the "Resources" tab. Then, when re-selecting the timelines tab, the scroll position is lost. This is particularly painful when you're digging deep in a stack trace.
<rdar://problem/24029669>
<rdar://problem/24029670>
(In reply to comment #0) > When viewing the Timelines view for "JavaScript & Events", and pressing the > right arrow on a particular function name, we're taken to the "Resources" > tab. The resource view should open in the timeline recording content view. It shouldn't jump to the Resources tab. > Then, when re-selecting the timelines tab, the scroll position is lost. This > is particularly painful when you're digging deep in a stack trace. I reproduced this by clicking the "back" button in the navigation bar to return to the script timeline after navigating to the resource. Interestingly, the scroll position is only lost when using the go-to arrow in the Location grid column. The arrow in the Records tree doesn't seem to have this problem.
The goto arrows in the tree and grid have different click event handlers. Each eventually call WebInspector.showSourceCode, but with slightly different arguments. Should have a patch soon.
(In reply to comment #4) > The goto arrows in the tree and grid have different click event handlers. > Each eventually call WebInspector.showSourceCode, but with slightly > different arguments. Should have a patch soon. Actually both handlers end up calling WebInspector.showSourceCode with identical arguments. The problem is that click the arrow in the tree causes a tree element to be selected, causing TreeOutline.processingSelectionChange to be true when the ContentBrowserTabContentView processes the changing content view. When the flag is true, it returns early. When clicking the goto arrow from the grid, the flag will not be set, and ContentBrowserTabContentView handles the changing content view notification. The first tree element with a represented object matching that the new content view is selected, causing the tree selection to change. Not only can this cause the root tree element of a call stack to get selected, but a different call stack in the same resource can be selected.
Good debugging! Seems like this will go away soon with the new timeline tab view architecture (and the removal of the sidebar tree and data grid.) Though, does this affect Network tab (which won't get the same timeline changes)?