Lamest Uploader bug ever (fixed) and testing on fast networks

Justin Obara obara.justin at gmail.com
Tue Sep 20 20:06:00 UTC 2011


I've reviewed and pushed the fixes for this up to the project repo. Heidi was kind enough to test it out again, and things look like they are working much better now. We've all been working really hard over these last couple of releases, and it's easy to overlook these things. Going forward we'll do a better job.  As for how to properly test for this. I can't yet think of a full proof way, other than making sure we have remote testers helping us out. 

Thanks
Justin
On 2011-09-19, at 7:03 PM, Clark, Colin wrote:

> 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 - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work




More information about the fluid-work mailing list