Progress bar shows progress only for last file when set to unlimited (with exceptions)
| Project: | FileField |
| Version: | 6.x-3.x-dev |
| Component: | Code |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
During upload, progress is only shown in the last progress bar when the field is set to unlimited "number of values" (files).
For example, If three upload file input-fields are shown, and I click Upload on the 1st, then click Upload on the 2nd, etc... I observe that only the last file's bar shows progress. The others say "Starting upload" throughout the upload. I know they're uploading because I'm watching the /tmp directory with #> watch -n1 'ls -l /tmp' and see the temp files appear and grow.
I am able to find exceptions. For example, say my node has six files already uploaded. I edit the node and remove the first three. I now have three empty input-fields followed by three files. I can now browse to any/all of the first three and click their corresponding Upload buttons, in any order. All 3 progress bars work and show progress.
But if I then click Add-another (remember, there will already be an open input-filed at the bottom) now making two open input-fields at the bottom, then old the last one will show progress (whether simultaneous or one at a time).
Also, if I edit the content-type's field, and change it to some number 1-10, then progress bars work fine in all the combination I've tried.
I see this with FF3 and IE7.
I realize that the progress bar is a very new addition, but I eager to help by testing!

#1
i bet its the UPLOAD_IDENTIFIER issue
#2
I think it's my apache setup, actually. We're using SSLVerifyClient Require in a subdir under SSLVerifyClient Optional. This (and other stuff) force a short ssl session cache timeout, and this in turn causes ssl renegotiation requests, between which apache buffers the post before handing it off to the handlers. We looked at this a LOT and plan to rearchitect to eliminate the post buffering problem.
I should have posted a followup. Oops.
#3
Thanks mudd, I wasn't able to reproduce this issue at all either. Let's mark as fixed and reopen if we can get any confirming reports.
#4
Automatically closed -- issue fixed for 2 weeks with no activity.