Bug 129470
| Summary: | [GTK] WebKit1 downloads not working | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Ben Boeckel <mathstuf> |
| Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | Major | CC: | cgarcia |
| Priority: | P3 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | PC | ||
| OS: | Linux | ||
Ben Boeckel
It's been happening for a while AFAICT, but I've finally had the time to chase it down. My guess is that it broke in v2.3.3[1] (I'm running 2.3.90 right now) with the change over to didReceiveBuffer rather than didReceiveData. The behavior is that I call webkit_download_start and then…nothing. No data received, signals called, status change, not a thing. If while in gdb, inside of webkit_download_start, I do "call download->priv->resourceHandle.m_ptr->start()' at the end of the function, then continue executing uzbl, the download successfully completes. I doubt it's the correct behavior, but something, somewhere, stopped calling start on the handle.
[1]All I have is a git history of tarballs; the official repo is way too large for my bandwidth to handle.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Ben Boeckel
I found my problem. When I had ported over to WebKit2, the download destination was determined asynchronously, but WebKit1's download mechanism calls _start and _cancel on its own, so if we're async, the destination isn't set when the download is started by WebKit itself, implicitly and silently cancelling it. The fix is to make the WebKit1 code sync.