When you try to download a file (ex. http://releases.mozilla.org/pub/mozilla.org/firefox/nightly/2009-11-21-03-mozilla-1.9.2/firefox-3.6b4pre.en-US.wince-arm.cab) using the latest firefox nightly build [Mozilla/5.0(Windows; u; WindowsCE 6.0; en-US; rv:1.9.2b4pre) Gecko/20091123 Namoroka/3.6b4pre], it claims to have successfully downloaded the file, however it has actually failed to pull down the whole file (usually pulls somewhere less than 1.6mb of the 27.9mb file). This is the same behavior I observed in the SUTAgent (WinCE automation project native stub) when using a stack variable for the network buffer and the Wininet functions within WinCE. When this was changed in the SUTAgent to a globally allocated buffer the file began to be consistently downloaded in it's entirety. = Steps = 1) Goto url - http://releases.mozilla.org/pub/mozilla.org/firefox/nightly/2009-11-21-03-mozilla-1.9.2/firefox-3.6b4pre.en-US.wince-arm.cab 2) Verify file download.
Ugh. This could be a big problem if it can't download full updates. (Although I know I've tested that recently due to bug 527845, so maybe this is a intermittent problem or recent regression.)
Bob: does it always stop at the same point? If not, how much does it tend to vary by?
Justin: It doesn't always stop at the same point but the variance seems to fall within around a mb +/- (say 500k - 1.6mb).
I'm able to reliably reproduce this on a trunk WinCE build, downloading big files from ftp://ftp.mozilla.org and http://dolske.net/mozilla/tests/video/. sdwilsh said there's a long standing download manager bug for the issue (bug 237623), but I can also reproduce this by just loading a tinderbox build log. I see a lot of variance, often at the 1-2MB point, sometimes 4x that.
Interestingly, the download seems to reliably work when I run it through my slowsend script at a reduced rate. EG, http://dolske.net/mozilla/tests/video/slowsend.php?rate=200 Might be speed/timing related, perhaps an OS buffer running out of space when the client isn't emptying it fast enough?
This looks likely to be an OS bug. I tested downloading a Ubuntu ISO from our internal fileserver (fs), both with WiFi and wired ethernet using the external debug board. The WiFi download croaked after 2MB, while the wired connection was able to download the whole thing (500+MB). I'll file a bug with NVidia. Clearing blocking nom here, since I don't think there's any way for us to reasonably fix this on our end (or, tbh, block the release until an OS fix is available).
WinCE/Windows Mobile support has been removed from the main build system, Spidermonkey, mobile installer, in-app updater and so on (see bug 614720, bug 554087 and all their dependants). Until such point where MS decide to release a Windows Phone 7 NDK and the decision is made to port to that platform, this is WONTFIX. Filter bugmail on WinCEMassWONTFIX.