Tuesday, October 23, 2007

SWFUpload Revision 7 beta 3

I decided I'd better get beta 3 out there. I've been too busy to test it and the demos as well as I'd have liked to so please forgive anything I've neglected. The updated demos and source have been posted in the usual place.

  • Fixed the Flash Version Detection. SWFUpload "should" properly detect Flash Player v9.0.28.
  • Fixed a left-over event call when cancelling an upload.
  • Fixed out of order parameters when calling uploadError.
  • Changed the showUI function and ui_function setting to swfUploadLoaded/swfupload_loaded_handler. This is more in line with other event callbacks.
  • Updated internal flashReady event so it is called like the other events (with setTimeout).
  • Added an internal event queue which fixes out of order events in Safari (out of order events were caused by using setTimeout to call them, just as I feared).

New Known Issues

If an upload is cancelled after the progress has reached 100% but before the upload script has finished processing then SWFUpload blocks until the upload script has completed. uploadComplete and fileComplete are still called along with uploadError. I'm still working out the best way to handle this situation (and have received some very good ideas in the comments).

To avoid this issue don't use the cancel feature or track your file progress in the JavaScript and prevent cancel calls to 100% still processing files. The issue will be fixed before the final 7.0 release.

You can test this by performing a long running process in your upload script. In PHP I tested by adding a sleep(30) statement. This causes SWFUpload to progress to 100% and then pause for 30 seconds while the upload script sleeps.


I'm considering removing the ui_container and degraded_container settings. This would remove the last UI modifying bits in SWFUpload. A hands-off approach to the UI has been one of SWFUpload's design philosophies. I wondered what everyone else thinks about that.

Rather than remove them completely, however, I'd keep a default swfUploadLoaded handler that uses ui_container and degraded_container which could be stored in the customSettings object. That would keep a simple graceful degradation feature built in while better separating SWFUpload from the UI.


  1. thorn5:55 AM

    Handlers.js in ASP.NET demo contains reference to thumbnail.php.
    And thumbnails doesn't appear in Firefox in this demo.

  2. thorn7:26 AM

    ASP.NET demo in Firefox doesn't keep thumbnail data to Session for some reason. In IE it works OK.

  3. thorn8:10 AM

    I've compared this demo with its PHP version and the reason is clear as noonday now:

    post_params: {"PHPSESSID": "<?php echo session_id(); ?>"},

  4. Sorry about those ASP.Net probelms. That demo is hard to keep up to date. I just port changes in to the zip files without really testing. I'll get those things fixed.

    As for the automatic cookie thingy. I never really liked having that feature in SWFUpload for some reason. I guess it doesn't feel like the "right way". If you want to set those values it seems like the server should do it. I.e., the <?php echo session_id();?> style. In the future I plan to make some "plug-in" javascripts that will allow you to add features like this outside the core SWFUpload.

    Regardless, in ASP.Net you cannot (as far as I know) change the session ID. Having the automatic cookie sending feature does do any good. (That feature did actually send the cookies by the way. It just took them and converted them to POST values and sent them along so you could manually get at them in your upload script)

    The Flash Player has a bug that affects Firefox (and other browsers, but not IE) and it does not send the cookies to the upload script. This means your cookie based authentication and session are lost when uploading with SWFUpload in FireFix, Opera, Safari, etc.

    This is an old bug that you can find out lots about at the Official Forums. PHP has a pretty easy work-around, which you've seen. Pass in the session_id as a post param and then in upload.php you get the session_id and manually restore the session.

    Unfortunately this does not work in ASP.Net and so using Sessions with SWFUpload and ASP.Net only works with IE.

    I managed to work around this in my ASP.Net applications by not using sessions in upload.aspx and disabling authentication for upload.aspx. It's not ideal but Adobe still hasn't fixed the bug and no one has presented a work around for manually restoring the session. There is a work-around at the Forums for manually restoring ASP.Net forms authentication.

  5. Hello There,

    I am little confused regarding swfUpload (original) Vs swfUpload R* series.

    I am supposed to be writing a mulitple file uploader so I wanted to check which script to go ahead with.

    How different is this R* series from the original swfUpload script? Does it provide some more method over and above wat swfUpload provides?

    Please let me know when you have a moment.


  6. frankblack7:02 AM

    Nice version! As always!! ;-)

    Could you give me a hint on how to display the already uploaded bytes like in the debug window? Would be a nice addon.

    Sorry for posting here again, because registration failed on the swfupload-site, already wrote to the contact email.

  7. thorn9:50 AM

    jake, yes, you're right about cookies.

    http://livedocs.adobe.com/flex/2/langref/flash/net/URLRequest.html#requestHeaders says:

    The FileReference.upload() and FileReference.download() methods do not support the URLRequest.requestHeaders parameter.

  8. @mandy: See my response in the SWFUpload forums.

    @frankblack: The SWFUpload forums are pretty much unsupported. Send me an email @ otijim__yahoo__com and I'll see what I can do (I'm a moderator there). We are moving to a new website very soon so it won't matter much anyways.

    SWFUpload has a method called debugMessage which will write to the built in debug console. Just call this from within the uploadProgress event. You can also call the debug event which will also write to the built in console but is queued up with the other events and so may not be executed right away.

    @thorn: That's right. I even tried it out (just in case since the livedocs are not always accurate). It didn't work. Flash Player just plain has a bug and there isn't a very good work-around. Passing in needed values with the Post is the best we could come up with and it doesn't work for everything :(

  9. thorn4:53 AM

    You can download repaired ASP.NET demo here:

    (Application is used instead of Session.)

  10. I send my upload_url to "upload.php".
    Then in that script, after i handle the mysql stuff, i would like to call a javascript code to insert the uploaded photo to a WYSIWYG textarea.

    This method works fine when i just a normal file upload code, but when i use swfupload, the script never gets called in the upload.php file.

    any reason?
    (I tried to call the code in handlers.js, and it works. however, in this file, i can't get the require param from the upload.php file)


  11. Whith multiuploaddemo i use this code to upload the files.

    $upload_path = str_replace("\\", "/", realpath(dirname($_SERVER['SCRIPT_FILENAME']))) . "/uploads/";
    $upload_path = "uploads/";

    // Handle the upload
    if (!move_uploaded_file($_FILES["Filedata"]["tmp_name"], $upload_path . $_FILES["Filedata"]["name"])) {
    header("HTTP/1.0 500 Internal Server Error");

    why whith formsdemo it doesn't work?


  12. In the forms demo there is a setting that changes the "Filedata" name to "resume_file"

    So you'll want to change/remove that setting or change $_FILES["Filedata"] to $_FILES["resume_file"]

  13. Great jake, thank you.

  14. In the coming version, would it be possible to add the file modification date to the file object that is passed to the file queued event? Currently, only the file_reference.creationDate is passed. It would be a simple matter of adding the file_reference.modificationDate in FileItem.ToJavaScriptObject() method. Thanks.

  15. I'll do that. It seems like I didn't include it because during testing the creationDate and modificationDate were always the same.

    But, either way I'll add that in.