New issue
Advanced search Search tips

Issue 723643 link

Starred by 3 users

Issue metadata

Status: Duplicate
Merged: issue 723748
Owner: ----
Closed: May 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Chrome gets stuck at "Processing response", failing to load page

Project Member Reported by pmeenan@chromium.org, May 17 2017

Issue description

We are seeing an interesting issue with a specific site when it is being tested on WebPageTest in Chrome but only when the connection is traffic-shaped to slow it down. IE and Firefox don't have similar issues.

The status message will get stuck with a "Processing request" message and won't proceed any further.  The actual request it gets stuck on (at least the last message in the Network.* log of messages) changes.

The trace and netlog don't show anything suspicious and connecting a debugger to Chrome after it is in this state shows all of the threads in the renderer and browser process sitting in their various run loops waiting for messages (i.e. idle).

It's possible that it is tied to remote debug protocol and some interaction but even disabling everything except for Page.* interactions doesn't make it go away (but testing manually without remote debug connected in the same environment doesn't trigger it - even loading in a separate tab in the same session).

Github Issue with some of the discussion is here: https://github.com/WPO-Foundation/webpagetest/issues/877

Test result with trace and netlog is here: https://www.webpagetest.org/result/170517_BT_f762002e35781ff9ed6c90924329e68b/
 
Patrick, any idea if this only occurs with DevTools's traffic shaping or on slow connections / system level traffic shaping?
This was with dummynet, not the internal shaping.  I'll see if I can reproduce it navigating directly from the command-line without any dev tools interaction at all.

It may also be related to https://bugs.chromium.org/p/chromium/issues/detail?id=723748 which was discovered after this was reported.  Digging through the failure netlogs now to see if it has a similar issue of requests getting stalled.
Mergedinto: 723748
Status: Duplicate (was: Untriaged)
Turns out it is the same HTTP/2 bug where requests are getting stalled in the socket pool that is being investigated in 723748

Sign in to add a comment