Using the per-revision bisect providing the bisect results,
Good build:59.0.3048.0 (Revision:458590).
Bad build:59.0.3049.0 (Revision:458956).

You are probably looking for a change made after 458872 (known good), but no later than 458873 (first known bad).

CHANGE-LOG URL:
---------------
https://chromium.googlesource.com/chromium/src/+log/dc1b7769eed1d73893db064c67e8187a2dfb9b7a..098645c6ee78757f03819207645ff151b8edf01d

From the CL above, assigning the issue to the concern owner

@eostroukhov: Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner.

Review-Url:  https://codereview.chromium.org/2747123008
Note :Able to reproduce the issue in Win 10.0,Ubuntu 14.04 & Mac 10.12.3 and Able to reproduce in latest Canary #59.0.3056.0

Correction in change log URL : https://chromium.googlesource.com/chromium/src/+log/da4bc538cc6b36cf5246f3dfcca30562a43d4947..8f7c3a1ade6b01cb90a8648d1e4dbfeab14bd8a5

Adding RB Label as this is a recent Regression. Please remove if not required.
Thank You.

I am not able to reproduce it. Could it be that it was fixed or is it Windows specific? Also, I don't think this blocks the release.

 Issue 703080  has been merged into this issue.

With response to comment #4 :
Rechecked the above issue on Windows OS with latest canary chrome version : 59.0.3062.0 and the issue is still reproducible.Kindly refer the attached screen cast for your reference

Deleted: Actual_video.mp4 446 KB

	Actual_video.mp4 446 KB View Download

Ok, I managed to reproduce this. Seems to require specific width of the devtools panel.

Looks like a layout bug.

Here's what happens:
1. Line from a mouse event handler dies this.listItemElement.classList.add('hovered');
2. This triggers CSS rule that makes the nested span visible with the change display: (none -> block).

No relayout is caused when the class is removed.

I only see this when the class is added from a mouse handler - e.g. doing the same from the console does not trigger the layout (even though the span becomes visible)

There is only a single change in the regression range and it specifically involves the pane in question:
https://chromium.googlesource.com/chromium/src/+/8f7c3a1ade6b01cb90a8648d1e4dbfeab14bd8a5

The change in question only fixed a bug in DevTools that was hiding the layout issue. Jumping is caused by a style change in the onmousemove handler. Positioning does not revert to the previous state after the style change is reverted (as the class gets removed).

This is a P1 regression where the CL that caused the regression is known. Whether the root cause is elsewhere is irrelevant. Our policy is to fix the manifestation of the regression (usually by reverting the relevant change) and then look into the root cause when the time pressure has been lifted.

While this might be a layout bug it seems somewhat unlikely given the bug only manifests when triggered from a mouse handler, layout doesn't care about the cause of a layout. Switching between display: none and block is also a very common thing to do, again suggestion that there is more to it. 

Either way, if you believe this is layout issue then please file a separate bug for that and assign it to me or leave it Untriaged. *This* bug is about a P1 regression in devtools caused by https://chromium.googlesource.com/chromium/src/+/8f7c3a1ade6b01cb90a8648d1e4dbfeab14bd8a5

As far as DevTools is concerned, this is a P3. It seems to be a more general issue with the layout. I defer to you to prioritize.

Closing as WontFIX based on comment 13.