[Webkit-unassigned] [Bug 201031] New: [GTK][WPE] Some pages won't load and network process chews 100% of CPU

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=201031

            Bug ID: 201031
           Summary: [GTK][WPE] Some pages won't load and network process
                    chews 100% of CPU
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Page Loading
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: aperez at igalia.com
                CC: beidson at apple.com

This can be reproduced reliably with MiniBrowser (also Epiphany)
with any recent build from “trunk”, opening the following URL:

  https://travis-ci.com/Igalia/cog

If you have the Web Inspector open while trying to load the page,
you will see that the main resource and most “normal” resources
(CSS, JS, etc.) load fine, then at some point two XHRs (one to
“*.statuspage.io” and another to “api.travis-ci.com”) seem to be
stalled and no doing any progress — it is unclear to me at the
moment whether these are the root cause or not, though. Sometimes
other resources may show as stalled in the inspector as well, if
their load has started *afterwards* (not necessarily XHRs).

Once this point is reached, the network process spins up to 100%
CPU time usage, and it does not seem to handle requests anymore:
this can be easily noticed by opening a second tab and trying to
load some other page (spoiler: it won't load). Killing the network
process will force spawning of a new one, which makes the browser
usable again — but of course the Travis-CI page is not usable,
because it failed to load some resources earlier and its network
process (the killed one) is gone.

In general, any Travis-CI project overview page triggers it, and
as far as I can remember this has been happening for at least
two or three weeks (maybe a bit more). I just now found how to
reliably trigger the problem.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190822/76e71d21/attachment-0001.html>