@lmfinney-- Could you please provide us the sample test url to reproduce the issue and also help us by providing the screencast for the issue , that would help us in triaging the issue better.

Thanks!

As I said, I can't give you the url that I'm working on because it's an internal website, but I can partially duplicate the problem using https://www.websocket.org/echo.html.

1. Navigate to https://www.websocket.org/echo.html
2. Open Dev Tools
3. Click on the Network tab
4. Click on WS to see the WebSocket data (I see one socket here)
5. Click on the "Connect" button on the website (I now see two sockets)
5. Click on the second socket in the list (for me, the name is "?encoding=text")
6. Click on the "Send" button on the website.

At this point, the websocket view jumps to the first socket in the list, away from "?encoding=text", and I have to click again on "?encoding=text" to see what I just sent.

In this app, it's not very annoying, but in our app the socket has a sub-second heartbeat, so the focus is pulled away almost immediately after I click on it, so I don't get to see the socket communication.

I will record a screencast with our actual app and post it later today.

Thank you for providing more feedback. Adding requester "hdodda@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Unfortunately, I can't install the screencasting software I know (https://screencast-o-matic.com/screen_recorder) on my machine at work, so I can't give you an original screencast. I hope the https://www.websocket.org/echo.html example is sufficient.

Yo, confirming this bug in Chrome 58.0.3029.110 (64-bit) on Win10 and here is the screencast of problem so you can better imagine - https://www.youtube.com/watch?v=BOg8aTRt7rM

I think the problem is that websocket window changes focus to websocket with recent communication. Here I have two websockets each with keep alive messages and the focus is just jumping between them.

Able to reproduce the issue on Windows 10, Mac 10.12.4 and Ubuntu 14.04 using reported version #58.0.3029.110 but the same is not reproducible in the latest canary #60.0.3111.0.

Reverse Bisect Information:
=====================
Good build: 60.0.3085.0  Revision(468227)
Bad Build : 60.0.3084.0  Revision(468182)

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/0a54e8804a182388f0aedc8a18524eaa10e76b85..fc4b4d8fbe2657a7d51cef8939e68acc99fae05a

From the above change log possible CL that fixed this issue:
Review-Url: https://codereview.chromium.org/2838673003

allada@ - Could you please check and merge the fix to M60 if it is a valid candidate.

Note: Adding label ReleaseBlock-Stable, as it seems to be a recent regression.

Thanks...!!

For the time being, a workaround is to use the filter field above the list of websockets such that the websocket you are interested in is the only websocket listed (or at least the offending websocket with a heartbeat is excluded from the list).

Credits to Tarek El-Sibay in https://groups.google.com/forum/#!topic/google-chrome-developer-tools/sJn5V3yfarU

Your bug is tagged as Release block, please have a fix ASAP.We will take only critical merges when close to Stable.

Unable to reproduce the issue on Win-10 using latest stable version #59.0.3071.86 and latest canary #61.0.3131.0.

lmfinney@ - Could you please upgrade chrome to latest stable version #59.0.3071.86 or latest canary #61.0.3131.0 and check the issue. 
Please let us know if the issue persist or not.

Thanks...!!

I can confirm that its working now with #59.0.3071.86 on Win10, good job guys! 

As per comment #10, it seems the issue has been fixed in latest stable #59.0.3071.86.
allada@ - Could you please update the status.

Thanks...!!

Yes this was fixed in a previous patch. I just forgot to merge this bug with the origin bug.

[Auto-generated comment by a script] We noticed that this issue is targeted for M-60; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-60 label, otherwise remove Merge-TBD label. Thanks.

Has this bug been merged to M60? Branch:3112

This bug should have been fixed in 59 and 60, yes.