Issue metadata
Sign in to add a comment
|
Network request selection jumps to next item when viewing WebSocket request
Reported by
nearw...@gmail.com,
Apr 21 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36 Steps to reproduce the problem: 1. On a site which uses WebSockets and WS Keep Alive (Ping/Pong), open the network tab of the dev tools 2. Select the Websocket connection request (doesn't have to be frames tab of that, just the URL of the websocket request. 3. Wait What is the expected behavior? Websocket request will remain selected What went wrong? The network request list jumps to the next item after period of time. Did this work before? Yes 59 Chrome version: 60.0.3076.0 Channel: canary OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version:
,
Apr 28 2017
,
Apr 29 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/fc4b4d8fbe2657a7d51cef8939e68acc99fae05a commit fc4b4d8fbe2657a7d51cef8939e68acc99fae05a Author: allada <allada@chromium.org> Date: Sat Apr 29 00:09:54 2017 [Devtools][Regression] Fixed websocket frame selection loss on frame received Fixed bug where if a websocket frame was received it would sometimes move the selected node in network panel to a new request. Offending patch: https://codereview.chromium.org/2694103007 R=dgozman,caseq BUG= 714229 Review-Url: https://codereview.chromium.org/2838673003 Cr-Commit-Position: refs/heads/master@{#468185} [modify] https://crrev.com/fc4b4d8fbe2657a7d51cef8939e68acc99fae05a/third_party/WebKit/LayoutTests/http/tests/inspector/network-test.js [add] https://crrev.com/fc4b4d8fbe2657a7d51cef8939e68acc99fae05a/third_party/WebKit/LayoutTests/http/tests/inspector/websocket/network-preserve-selection-on-frame-receive-expected.txt [add] https://crrev.com/fc4b4d8fbe2657a7d51cef8939e68acc99fae05a/third_party/WebKit/LayoutTests/http/tests/inspector/websocket/network-preserve-selection-on-frame-receive.html [modify] https://crrev.com/fc4b4d8fbe2657a7d51cef8939e68acc99fae05a/third_party/WebKit/Source/devtools/front_end/network/NetworkLogView.js
,
May 1 2017
This has landed on Canary and I'll push it to beta in a few days.
,
May 1 2017
,
May 1 2017
Your change meets the bar and is auto-approved for M59. Please go ahead and merge the CL to branch 3071 manually. Please contact milestone owner if you have questions. Owners: amineer@(Android), cmasso@(iOS), gkihumba@(ChromeOS), Abdul Syed@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 4 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2f488c5dbee60477aec562eff18a41e022aa5390 commit 2f488c5dbee60477aec562eff18a41e022aa5390 Author: Nathan Bruer <allada@chromium.org> Date: Thu May 04 17:32:12 2017 [Devtools][Regression] Fixed websocket frame selection loss on frame received Fixed bug where if a websocket frame was received it would sometimes move the selected node in network panel to a new request. Offending patch: https://codereview.chromium.org/2694103007 R=dgozman,caseq BUG= 714229 Review-Url: https://codereview.chromium.org/2838673003 Cr-Commit-Position: refs/heads/master@{#468185} (cherry picked from commit fc4b4d8fbe2657a7d51cef8939e68acc99fae05a) Review-Url: https://codereview.chromium.org/2857673005 . Cr-Commit-Position: refs/branch-heads/3071@{#404} Cr-Branched-From: a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641} [modify] https://crrev.com/2f488c5dbee60477aec562eff18a41e022aa5390/third_party/WebKit/LayoutTests/http/tests/inspector/network-test.js [add] https://crrev.com/2f488c5dbee60477aec562eff18a41e022aa5390/third_party/WebKit/LayoutTests/http/tests/inspector/websocket/network-preserve-selection-on-frame-receive-expected.txt [add] https://crrev.com/2f488c5dbee60477aec562eff18a41e022aa5390/third_party/WebKit/LayoutTests/http/tests/inspector/websocket/network-preserve-selection-on-frame-receive.html [modify] https://crrev.com/2f488c5dbee60477aec562eff18a41e022aa5390/third_party/WebKit/Source/devtools/front_end/network/NetworkLogView.js
,
May 4 2017
This should be fixed in the next chrome release. Sadly we didn't make the recent beta cut for this, so we have to wait ~5-6 weeks for it to land on stable.
,
May 4 2017
Issue 718418 has been merged into this issue.
,
May 5 2017
Issue 718775 has been merged into this issue.
,
May 10 2017
allada@, Could you please provide us the sample website/URL to verify this issue from TE end. Thanks in advance..!!
,
May 10 2017
Verified the fix with Chrome 59.0.3071.47 on Windows 7 and 10, Please find the steps followed below : 1. Open the Developer Tools and go to the Network Tab BEFORE you go to a website that has websockets (i.e. http://www.websocket.org/echo.html) 2. Click on "Connect" on the site 3. Look for the 101 status and click on the "Name" of the resource 4. Click on the "Frames" tab 5. Click "Send" on the Site Expected : I should see the frames coming in and going out of the browser
,
Jul 7 2017
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by caseq@chromium.org
, Apr 23 2017Owner: allada@chromium.org
Status: Assigned (was: Unconfirmed)