When uploading multiple files via drag-and-drop, Confluence never recovers to complete subsequent transfers if any server-reported error occurs on a previous file in the list.

For example, I navigated to a simple page containing the Attachments macro as a regular user.

To provoke a sever-side error, I logged in as an admin in another window and removed the "Attach files" permission for the first user.

I then switched back to the first user's context and dragged two files, cache.properties and oscache.properties, into the drag and drop container.

The results are as shown in the screenshot: the first error message is received from the server and displayed correctly, but the following file is stuck in the queue with "Waiting" and the transfer never completes.

Although this example is not a demonstration of real-world use, there are other situations in which the server-side validation should work properly, such as uploading a too-large file or one with invalid characters, out-of-disk-space errors, or in third party integrations (such as in our Lockpoint product, which needs to report when files are locked and inaccessible to the current user without blocking the remaining uploads).

The bug appears to be in the drag-and-drop plugin in plupload.js:

				self.bind("Error", function(up, err) {
					// Set failed status if an error occured on a file
					if (err.file) {
						err.file.status = plupload.FAILED;
						calc();

						// Upload next file but detach it from the error event
						// since other custom listeners might want to stop the queue
						if (up.state == plupload.STARTED) {

                            //ATLASSIAN - handle the case where we subsequently drag files in and there is an error
                            // We very likely already have a file that is uploading - so don't start uploading the next file
                            if (!hasRunningFiles()) {
                                delay(function() {
                                    uploadNext.call(self);
                                }, 1);
                            }
						}
					}
				});

Just after the "//ATLASSIAN" comment, the "hasRunningFiles()" function returns true because more than one file is still queued (total.queued==1, as you can see in the attached Firebug screenshot). But this code means that uploadNext.call(self) is never called, so Confluence never gets around to uploading the next file.