Hi everyone, It looks like I caused (and fixed) the lamest Uploader bug ever, starting at Infusion 1.3 when we introduced the HTML5 implementation.
Somehow, in my imagination, our Uploader had some crazy semantics for progress events, where it needed the number of bytes uploaded since the last progress event, rather than the total number of bytes complete. Instead of looking closely at the code, I just went ahead with the unnecessary effort of writing code to ensure this crazy information was passed by the HTML5Strategy to the FileQueueView. The result was unpredictable, reversing progress bars and summaries. Erm, oops. Here's a pull request: https://github.com/fluid-project/infusion/pull/168 We never really noticed this issue because we've been testing with locally-hosted servers and very fast networks. Running the Uploader server locally, the speed is just so fast that the browser will likely never fire more than one progress event. Even across OCAD's network to our build server, more than one progress event is unlikely for all but the hugest files. It was Heidi who caught this issue on her home network, and I was able to confirm while at a conference (you know how those networks are). So, I'm wondering if people have any suggestions for QA testing techniques we can use to simulate slower upload speeds without mocking out any of Uploader's actual implementation? Colin --- Colin Clark Lead Software Architect, Inclusive Design Research Centre, OCAD University http://inclusivedesign.ca _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
