Three Errors.

Sep 9, 2011 at 5:42 PM

I have a fairly complex implementation using mpost.SilverlightMultiFileUpload.Lite MVC3 and JavaScript and have ran into the following three bugs.

  1. If a file is open (in Word for example) and you try to upload it the control throws a generic JavaScript error that is not catch-able (as far as I can tell).  I've fixed it by editing the MainPage.xaml.cs file and putting a Try Catch block around everything in the AddFiles function and catching System.IO.IOException and then throwing a System.Windows.Browser.HtmlPage.Window.Alert().  I've tried catching the generic error using the built in onerror function with no luck.  Am I doing something wrong?  Shouldn't it throw slCtl.Content.Files.ErrorOccurred?
  2. I'm running into strange JavaScript issues.  Everything will work (with the exception of Chrome, see #3 for that) and then when i make a change to my main JavaScript function (doesn't really matter where) it will sometimes start throwing errors saying slCtl.Content.Files.TotalPercentageChanged  (for example) is not a function.  It's a bit random which sub function of Files it suddenly stops liking.  Any idea why this would be?  if I clear my browsers cache and reload it tends to fix it.  This is not ideal for users obviously.  If we make a minor change to the JavaScript file and suddenly the upload control stops functioning, that's bad.  FireFox 6
  3. Lastly, my implementation of the File Upload control does not work in Chrome.  I know the demo ones do. I can't figure out the difference, other than all my JavaScript and mine is using HTTPS.  (I haven't' tested the demo pages under HTTPS yet).  It throws an error when you try to Save the files.  It's the SilverLight that is throwing the error using the slCtl.Content.Files.ErrorOccurred function in JavaScript.  Thoughts?

Thanks for your time and input!

Sep 12, 2011 at 6:09 PM

Thanks for the feedback!

1) Bug is fixed. I added a proper error message. If you're using the javascript mode, the files that can't be added are ignored. Bugfix is in latest changeset

2) Unable to reproduce that. If you have an example for me to reproduce it I can have a look at it.

3) Possible solution for this is to configure the full URL for the HttpUploadHandler, including HTTPS.
Example: <param name="initParams" value="UploadHandlerName=,etc......

If that does not work. Try debugging mpost.SilverlightMultiFileUpload.Utils.CustomUri and check the URL where the control is trying to send the files to.

Hope this helps,










Sep 12, 2011 at 9:29 PM

Mike, thanks for getting back to me.

I'll have to get the new source tonight when I go home. For some reason our security team can't fathom why our NetSense Proxy server is blocking source downloads for the control.  I've been getting them from home after work while they bug NetSense to try and fix it.

I'm pretty sure #2 has to do with super aggressive caching that FireFox is doing. I have to clear the cache completely for it to see code changes in the XAP file.

I've tried a bunch of stuff to get #3 to work to no avail.  I did try the full URL (to the controller) and that didn't work. I also turned off the HTTPS requirement in dev and used plain http and that didnt' work either.

I've debugged the suggested file and this is what I got.

Coming in: /Projects/File/FileUpload
Going out (i.e. strFullUrl):  http://localhost:49720//Projects/File/FileUpload

I can't imagine the // between the port number at Projects has anything to do with it (and the absolute path didn't fix it so . . )  It's browser specific which is what's weird.  I'd think if one browser had a problem with that path, all of them would, but I'm not a SilverLight expert.  Does it not like it not having a real file extension?  

FireFox and Chrome give back the same results for strFullUrl.

Any other ideas?

Sep 13, 2011 at 4:08 PM

More information about #2, I believe it may be actually be a memory leak in FireFox (no way!).

It just happened again and I tried wiping FF's cache and reloading and it did not fix it.  I had to close the browser and start fresh.

I've now wrapped the function that binds FilesAdded, ErrorOccured, SingleFileUploadFinished, etc. to their functions with a Try Catch block and warn the user that an error has occurred and they will probably have to close their browser to fix it.

I don't know if this a specific issue with the SilverLight control (probably not) or just the massive amount of JavaScript I have going on in the page causing FF to break due to it's memory leak issues.  Hopefully FF 7 fixes some of these memory leak issues.

Sep 13, 2011 at 4:09 PM

Still no luck with Chrome BTW.

Sep 13, 2011 at 6:18 PM

Are you able to create a little sample visual studio solution for me where Chrome does not work under https? So I can try to reproduce it and debug it?

Without that, I'm unable to reproduce it and fix it.


Sep 16, 2011 at 8:42 PM

Sorry it took me a couple days to get to this, been  busy.  I've created a sample MVC3 implementation.  It's stripped out of the project I'm working on.  Hope it helps.

I've uploaded it under the submit a patch function.

Let me know what you figure out and thanks for looking into it. 

Sep 16, 2011 at 9:28 PM


I was able to reproduce your error.
The error Chrome was giving was:
A potentially dangerous Request.Form value was detected from the client

You can fix this with two steps, first, modify your web.config and add this:
<httpRuntime requestValidationMode="2.0"/>

Put it inside the system.web tag:
    <httpRuntime requestValidationMode="2.0"/>

Step 2:

Add this line of code to the FileUpload method in your FileController:
[HttpPost, ValidateInput(false)]

 [HttpPost, ValidateInput(false)]
  public void FileUpload(int param, string file, long offset, bool last = false, bool first = false)

That fixed it. Let me know if this also works for you.


Sep 16, 2011 at 10:34 PM

Yeah, I had noticed those errors popping up in ELMAH this morning but it never occured to me that that would be the problem as it worked in other browsers.  

I dislike turning off the advanced request validation, but oh well, its an intranet app.


Thanks tons for your help!

Sep 17, 2011 at 7:21 AM

You're only turning the request validation off for that specific method, so that shouldnt be a problem.

It's still really strange that this server side error only happens when using Chrome and not in other browsers.