Summary: | Cannot abort multiple XHR POSTs made to same url | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Chris Cinelli <chris.cinelli> | ||||||
Component: | Page Loading | Assignee: | Nate Chapin <japhet> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | ap, beidson, dglazkov, japhet, koivisto, webkit.review.bot | ||||||
Priority: | P2 | ||||||||
Version: | 528+ (Nightly build) | ||||||||
Hardware: | All | ||||||||
OS: | All | ||||||||
Attachments: |
|
Description
Chris Cinelli
2013-01-15 12:34:46 PST
Confirmed with trunk. What I'm seeing is that XHR.abort() gets down to CachedResource::removeClient(). For first two requests, inCache() is false, so we don't call allClientsRemoved(), and thus don't actually cancel ResourceHandle. Only the third request has inCache() return true, and gets actually canceled. Nate, is this something you'd be willing to look into? To me, it just looks like allClientsRemoved() call should be made regardless of whether the resource is in cache, but perhaps there was a reason to make it conditional. (In reply to comment #1) > Confirmed with trunk. > > What I'm seeing is that XHR.abort() gets down to CachedResource::removeClient(). For first two requests, inCache() is false, so we don't call allClientsRemoved(), and thus don't actually cancel ResourceHandle. Only the third request has inCache() return true, and gets actually canceled. > > Nate, is this something you'd be willing to look into? To me, it just looks like allClientsRemoved() call should be made regardless of whether the resource is in cache, but perhaps there was a reason to make it conditional. I agree, it seems obvious that allClientsRemoved() should be called even if the resource is in cache, though it's not immediately obvious whether that holds true for everything else in the if (!deleted && !hasClients() && inCache()) block. I'll look into it. Created attachment 183055 [details]
patch
Comment on attachment 183055 [details] patch Attachment 183055 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/15901745 New failing tests: http/tests/inspector/network/network-disable-cache-xhrs.html Created attachment 183274 [details]
Fix ews failure
Not convinced this is the best fix to the network-disable-cache-xhrs.html failure, but it's simple at least. :/
Comment on attachment 183274 [details] Fix ews failure Clearing flags on attachment: 183274 Committed r140174: <http://trac.webkit.org/changeset/140174> All reviewed patches have been landed. Closing bug. |