Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Indicator in UI for FU during server-side file processing #404
Scenario: A file has finished uploading, but the server must do some non-trivial processing, such as sending the file to another storage location (such as S3).
Currently, after the last byte has been sent, the progress bar remains at "100%" until the server returns a response. Depending on the amount of work required server-side to process the file, it may be 10 or more seconds before that response can be sent. One way to mitigate this is to return the response at once and delegate processing to another thread, but if this processing fails, there is no way to alert the users via the Fine Uploader UI.
I think it would be nice to display some status text, perhaps next to the file (where the error message would normally appear). I'm guessing "barber pole" progress bar may be appropriate as well.
Note that this only applies to browsers that support the file/blob API. We cannot calculate upload progress with this support.
This case would only involve changes to FU. Users of FUB should be able to come up with their own UI using the exact algorithm you've specified.
First I'm looking to include some sort of a status message next to the file. For, example, if the file has finished uploading, but we are still waiting for a reply from the server, a specially formatted "Processing..." message would appear next to the file. Second, when this happens, the progress bar that comes standard with FU would turn into, perhaps, a barber pole...
There are other cases that would benefit from a mechanism to display temporary status information next to a file in FU, such as the auto/manual failed upload retry feature. In that case, during a retry, we would want to display "Retrying 2/3" next to the file, for example.
pushed a commit
Oct 30, 2012
Simply added common status message element to the FU template that, in this case, by default, says "Processing..." next to the file (with the spinner remaining and the progress bar hidden) when we have sent the last byte but are still waiting for a server response.
I also created what I'm calling a qQuery function in the utils section of the code. See the documentation for more details.
Plenty of refactoring in this case, with matching QUnit tests.
I noticed that Firefox doesn't fire its last progress event until it receives the response from the server, which is a bit of a bummer. There is a Firefox issue filed to track this "issue".
It sounds like Firefox might actually be following the letter of the XHR V2 spec, while Chrome is adhering to the "spirit" of the spec. Chrome's implementation, which results in the last progress event fired after the last byte has been "sent" is what most may expect, but this may just be a violation of the spec. Not sure what IE10 does yet as I haven't looked into that yet. A FF developer has opened a thread on w3.org, asking for some clarification.
A Chromium dev believes the "expected" behavior is actually a webkit detail, and not specific to Chrome. This suggests that Safari and Chrome exhibit the same behavior, which I have verified. It sounds like there is a push to adjust the spec to allow webkit's behavior to be the expected behavior (according to the letter of the spec).
Note that I am not using the "loadend" event to determine when the browser has finished sending the last byte. I'm simply comparing the "loaded" value with the "total" value when handling "progress" event notifications. If these two values are equal, I'm declaring the file "completely sent". According to the spec, I should be able to do this (I think) since the "loadend" event is simply fired after the last "progress" event. See the spec regarding the ProgressEvent for more details.