I am seeing a very odd thing happen with kendo UI's kendoUpload. I have implemented a custom UI for displaying the files being uploaded, along with a progress bar and a cancel button. Kendo does not offer an API for cancelling uploads, but I read here that you can tap into kendo's default upload progress display to cancel an upload. That is exactly what I did, with the following javascript function attached to my custom cancel button:
var fileName = _getFileNameForThisCancelButton();
var kendoUpload = $('#file_upload').data('kendoUpload');
if (kendoUpload) {
var cancelButton = kendoUpload.wrapper.find('ul.k-upload-files')
.find('.k-file:has([title="' + fileName + '"]) .k-cancel');
cancelButton.click();
}
This little function works as far as it does fire the kendoUpload's cancel event, and the network traffic stops, so data is apparently no longer being sent from the browser to the server.
However, as soon as one cancel button is clicked, any subsequent requests to the site from the browser where the cancel button was clicked hang forever. Note this is for the entire site, not just the file upload page, and only for the browser in question -- the site still loads in other browsers where upload cancel buttons have not been clicked. This goes for Chrome 30.0.1599.69 m, Firefox 20.0, and IE8.
With Firefox and IE, simply closing and restarting the browser causes the hanging to stop, and the site loads again. With Chrome I have found this doesn't work, and neither does logging out of my local machine -- I have to do a full reboot to get the site to load again in Chrome. I think this may have something to do with my Chrome settings though. I have it set up to load all of my last tabs when re-opening, and I have noticed that closing and re-opening Chrome also does not delete my login cookie for the site. Either way, It's the same issue even if it is harder to reset in Chrome.
So... any ideas what is going on here? It seems almost as if the browsers are still waiting for a response from the server for the cancelled upload and blocking on the entire site waiting for a response that will never be delivered.
Updates
Turns out I was right about Chrome. After disabling the "Continue where I left off" startup option, Chrome now behaves the same as FF and IE -- need to close and reopen the browser to get the site to load again.
I have also tried this without the custom UI, meaning I turned off showFileList: false when creating the widget and clicked the actual cancel button. Starting to wonder if this has anything to do with the POST method on the server...?
