[Webkit-unassigned] [Bug 137817] XMLHttpRequest(s) aborted when they should not be

[bugzilla-daemon at webkit.org]

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

Mirko Tschäni <mirko.tschaeni at unblu.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|DUPLICATE                   |---

--- Comment #2 from Mirko Tschäni <mirko.tschaeni at unblu.com> ---
I agree that this issue is a duplicate of https://bugs.webkit.org/show_bug.cgi?id=23933 technically. 
However there are two reasons why i thing resolving this as a duplicate is not ok.

1. The summary of bug 23933 suggests that the issue is only related to form submits when actually the issue affects any kind of navigation (to downloads but also browser renderable contents)

2. In the comments of bug23933 Alexey Proskuryakov suggests that download related issues should not be discussed in a bug that was filed about submitting forms.


Depending on the application i think this issue is close to impossible to work around. 

Imagine the following situation:

A site uses a third party java script that implements a embedded chat. As soon as the user clicks any link or submits a form that has a target of self, starting with the click until the response arrives, the third party chat will be unable to send any ajax request. Even worse, is is not event possible to detect this situation and the chat is unable to know whether this is some major issue (like a network outage) or just the user navigating to some other url. Especially if the server takes a while to respond (which is often the case for uploads, that's why this bug was first discovered there).
WebKit should wait with aborting ajax requests until the response has arrived, because only then webKit can decide whether the browsing context is to be unloaded or not.

If the response is browser renderable: do not abort
If the response is not browser renderable (by content type or because the response has a content-disposition: attachment header).

Please: either change the title of bug23933 and re priorise or do not mark this bug as a duplicate of 23933.

By the way: this issue has been fixed in the most recent versions of chrome/blink (chrome 36+)

-- 
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/20141021/f14673c7/attachment-0002.html>