What was happening was that between the moment that we queued up the next progress and the time that the progress actually happened, the user could click the Stop Upload button thus firing a bunch of other events. Depending on the timing of the click, different odd things would happen.
So instead of doing:
check if we can progress
set next progress on the timer
timer fires next progress
next progress
We need to
check if we can progress
set next progress on the timer
timer fires next progress
check if we can progress
next progress
I also removed the delay on finishUploading because this was another
place where the user could slip an event in, and it wasn't really
necessary for the simulation. At the point that the finishUpload
fires, we should not wait but start in immediately into the next file.
And I switched the code to use that.queue.isUploading instead of that.demoState.shouldPause which meant that pauseDemo could be simplified a little bit and we're using a consistent variable to checking the state of the upload.
Obviously this needs a very detailed review. - Eli
FLUID-1947.b.patch
Description: Binary data
. . . . . . . . . . . . . . . . . .
.
Eli Cochran
user interaction developer
ETS, UC Berkeley
_______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://fluidproject.org/mailman/listinfo/fluid-work
