Bug 274727
| Summary: | GNOME Discourse page loads forever | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Michael Catanzaro <mcatanzaro> |
| Component: | WebKitGTK | Assignee: | Michael Catanzaro <mcatanzaro> |
| Status: | NEW | ||
| Severity: | Normal | CC: | bugs-noreply, dave, mcatanzaro, webkit-bug-importer |
| Priority: | P2 | ||
| Version: | Other | ||
| Hardware: | PC | ||
| OS: | Linux | ||
Michael Catanzaro
Load https://discourse.gnome.org/t/gnome-46-2-stable-tarballs-due-responsible-mcatanzaro-gnome-45-7-oldstable-tarballs-due-responsible-mclasen/21123 in Epiphany Tech Preview (WebKitGTK 2.45.2). The page continues loading forever. It's downloading a special resource named poll, which indicates it's probably expected to never stop:
https://discourse.gnome.org/message-bus/85f137e8a73f45bfa17ff2b206f03105/poll
When this page is loaded in Firefox, the load finishes almost immediately, so I assume Firefox doesn't consider this subresource to be part of the initial page load.
Additionally, the Stop button does not stop the load. This is bug #242248.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Michael Catanzaro
Same bug happens on https://www.vox.com/future-perfect/352359/milk-dairy-schools where the subresource polyfill.min.js just never finishes loading. I've been loading this page for 4 minutes now and I doubt it will ever finish. Stop button does nothing.
I'm surprised there's no timeout.
Michael Catanzaro
I think the problem on www.vox.com is different.
The problem on discourse.gnome.org seems to occur whenever restoring the page from session state. Just loading the page directly seems to always work fine.
Michael Catanzaro
*** Bug 242248 has been marked as a duplicate of this bug. ***
Michael Catanzaro
Let's handle the vox.com problem in bug #275178.
Michael Catanzaro
(In reply to Michael Catanzaro from comment #2)
> The problem on discourse.gnome.org seems to occur whenever restoring the
> page from session state. Just loading the page directly seems to always work
> fine.
Well I have a fix, but it feels like the sort of change that really wants an API test. I don't know why the problem is specific to discourse.gnome.org, though. It doesn't happen for most pages restored from session state.
Michael Catanzaro
Pull request: https://github.com/WebKit/WebKit/pull/29557