Share This Using Popular Bookmarking Services

Google ads


network monitoring software

Programs & websites tailormade for you.

Testing the AjaxSafeUpload control 

Wednesday, August 17, 2011 1:37:00 PM

Last updated: 16/3 2012 at 19:30.
(Newest notes near the bottom.)

I am starting this new blog entry to document the testing progress for getting the AjaxSafeUpload production ready - that is: moving it from version 0.9 to 1.0.

It is important to know that the only way websites can select a file from your harddrive and upload it, is by using the <input type="file"> HTML tag. The AjaxSafeUpload control and the JavaScript tries to make it easier for programmers and designers by hiding this very unstandard HTML tag, but it is still there (invisibly placed over your button) and my code cannot introduce behaviour that the browser does not support.

So my definition of "works" is: pressing the styled button opens the window to select a file, and when it is selected it will be instantly uploaded, which result in the list of uploaded files to be correctly updated with the new entry.

For example: Some browsers cannot tell the JavaScript how much of the file is transferred, so they will not have any progress indicator - but if everything else works, then it fits my definition of "works", since the control is doing the best possible on that platform.


Browser testing so far has revealed:


iPad & iPhone 4:

Safari/WebKit on these devices does not support uploading files - period!

That means there is no way you can use an HTML website to upload pictures taken with your iPhone - meaning you need to write an app if you want that functionality.

v0.9.6 now displays an alternate text to direct the user to use a different browser, and that is the best I can do for iPad & iPhone


Android 2.3:

When clicking the attach button using the WebKit browser on my HTC Desire Z, it presents a dialogue to select a picture from the phone's image gallery. It does although incorrectly report all files as being of 0 length, so I had to disable the check for empty files in the JavaScript - but with that HTML websites can upload files from Android phones. (If you have a different Android with different behaviour, please let me know!)

Firefox on Android: Sometimes the browser would crash with a black screen after selecting an image - but when it does not crash then it works... In the demo website, the top button does not work in Firefox on Android - unknow why exactly this combination gives problems... In another test website (where the upload control is always visible) a single button always works, although there is still the crash problem of the browser...

Opera on Android: Styled button does not work - v0.9.9 offers a legacy mode for Opera Mobile with simply unstyled buttons that work. (Opera Mini gets the message that the browser is not supported.)

xScope browser on Android: Does not support uploading files at all, just like iPhone. Unfortunately it does not properly identify itself with a user agent (it is too similar to the buildt in WebKit browser), so I cannot write any warnings for users of this browser.

Dolphin browser on Android: Works like standard WebKit.

HTC FriendStream: After upgrading my Android it now shows twitter links in its own web browser instead of offering to open a browser - and this new buildt in browser does of course not work with selecting files... Once I get its user agent identified I'll try if my legacy mode will work with it.


Windows Phone 7 (pre-mango):

Can offer pictures just like Android, but its IE7 browser is somehow odd, so while normal upload buttons work, the styled upload button does not.

v0.9.9 offers a legacy mode for Windows Phone that works.


IE 8:



IE 9:


Note: When uploads fails due to files being bigger than the web.config allows (the JavaScript does not filter uploads based on size on IE), v0.9.6 will give a security warning. In coming v0.9.7 it has been fixed so there is no warning and the user gets the standard "Failed - try a smaller file." error message. Also note that IE 9 have some drag and drop events, but the JavaScript cannot handle them proberly - I have changed the JavaScript so it will ignore the errors introduced by IE9 (by disabling drag and drop in IE9 for now).


IE 7:

The list of uploaded files was not shown correctly in v0.9 - it is fixed in v0.9.1.

Generally IE 7 require a few extra div-tags with extra styling in order to recreate what one have done with Firefox and IE 8/9, so you have to test your own styled button too.

But the functionality of the button works as it should under Windows.


IE 6:

I am not really supporting this browser anymore on any of my websites - it is too much trouble. But besides that the layout might break, the functionality of the button and uploading files does actually work, so if you want the trouble of styling for it, feel free to go ahead and do it.


Firefox 5+:

Oh sorry, that version is not current anymore... Anyway, it was my main browser that I used for development, so it works perfectly.

When you allow multiple files Firefox 5+ will also allow you to select multiple files at once - in older browsers you probably have to select files for uploading one by one.


Firefox 3.8.20 / Windows:



FireFox 3.6.17 / Linux



IE 10:

Here the main problem is that ASP.NET by default will treat it as Internet Explorer 1 - or something else below IE 6. And the result is that no Ajax JavaScript for partical postbacks is generated, and therefor very little stuff will work...

But once you tweak ASP.NET to detect it correctly, then it works. The demo Web Application includes all the needed tweaking.


Unknown browsers:

As with the note for IE 10 above, ASP.NET will treat any unknown browser as having no JavaScript abilities, so everything that relies on MS-Ajax JavaScript being present will fail.

In the demo Web Application I have tried to adjust the defaults to lure MS-Ajax to always include its JavaScript magic stuff - but there is no guarantees.

Note that this might ruin accessibility - but I honestly don't think that an advanced graphical website using partial page updates can automatically be degraded to work for blind people using a one-line-at-the-time finger reader, and no amount of automatic testing for stuff like "descriptions on all pictures" will tell you if reading the page one line at the time will give any meaning at all! If you need to support different handicaps, then get hold of some handicapped as testers and find out which browsers they are using, and write/design something specifically for them. (And I would love to hear your test results from them!)


Chrome (newest version as pr. todays date):


Please note: From v0.9.5 I am using technology where ASP.NET 3.5+ might contain bugs in its handling of Chrome & Safari - a bugfix is included in  the demo project in the form of the "kmaPostAjax.js" file that is loaded after MS Ajax.



Safari 5.1 / Macintosh 10.6.8:


Please note: From v0.9.5 I am using technology where ASP.NET 3.5+ might contain bugs in its handling of Chrome & Safari - a bugfix is included in  the demo project in the form of the "kmaPostAjax.js" file that is loaded after MS Ajax.


Safari 5.0.1 / Windows:

Works - although Safari had trouble with focusing on the file browser window when I tested it, the control did work exactly the same as any ordinary file upload control, so it is not the JavaScript's fault.

Please note: From v0.9.5 I am using technology where ASP.NET 3.5+ might contain bugs in its handling of Chrome & Safari - a bugfix is included in  the demo project in the form of the "kmaPostAjax.js" file that is loaded after MS Ajax.


Opera 11.50 / Windows:



Konqueror 4.3.5 / Linux:

v0.9.9 offers a legacy mode for Konqueror that works.

Basically, Konqueror tries to change all HTML buttons to something that looks nicer on Linux, but the result is that styling attepts don't work.


Other bugs and integration tests:

DotNetNuke / MySQL

Successfully integrated into an older version of this portal (the styled example is from a custom module in an internal DotNetNuke website at my work).

(Note: DotNetNuke uses MS SQL Server, but I have chosen to use a totally different database and machine for storing uploaded files to keep the traffic away from the routine stuff in the web databases.)


mojoPortal / MySQL

Successfully integrated the demo page below a mojoPortal installation. But note that mojoPortal's own NeatUpload control has to be disabled for the AjaxSafeUpload folder with a web.config like this:

<location path="controls/upload">
   <neatUpload useHttpModule="false" ></neatUpload>
     <httpRuntime useFullyQualifiedRedirectUrl="true" maxRequestLength="48000" requestLengthDiskThreshold="256" />

It should be placed right after the normal <neatUpload useHttpModule="true"../> directive. Note that instead of having the web.config file in the /controls/upload folder, its contents has instead been put here inside the location statement.

For mojoPortal and other CMS systems who might want to include AjaxSafeUpload as an alternate upload handler, but who does not desire to be locked to a specific database implementation, version 0.10.0 of AjaxSafeUpload now also includes a Session-state + file storage alternative.


Sticky hover style

I think there must be a bug in Valum's original JavaScript in that it often forgets to remove the hover effect on the upload button. As a quick fix my MS-Ajax JavaScript add-on now removes the hover-style as soon as the upload starts.


Fine tuning styling

In v0.9.7 I have adjusted my default stylesheet a bit for the display of the list, and I have included the word "Wait:" after the spinning indication - this was because in some browsers the spinning thing will not spin while a full postback is happening to the hidden iframe, and on all the older browsers that require an iframe (that is: all IE 6-9+) plus those that does not in advance know the size of the file (Android) it is not possible to display a %-indicator for how much has been transferred.

While integrating my control on a work project I found that the 3 default texts was not enough, so in v0.9.9 it is possible to specify a custom text for the button, such as "Attach a CV". The title of the list of attachments gets changed to simply say "Attached:" when a custom text is used for the button.

I also needed for the displayed filename to be shorter, so I made options for specifying how long the filename is allowed to be, before it will be shortened on screen.

In using the control at my work, I have realised that I really need to be able to not just specify the button text, but also the title of the list, and the message shown when nothing is uploaded, so now in v0.10.0 all 3 texts can be specified in the control's properties.


MySQL max_packet_size - errors when uploading big files:

While testing it is very annoying to just get a "failed" with no additional information. Now v0.9.6 will when compiled in debug mode report the server exception message in the response, so you can use Firebug to see what happened.

But the most common error so far is trying to upload a file that is bigger than max_packet_size - while MySQL's Connecter/Net claims to support files up to 2GB, you need to configure the database to allow it, and if you are in a hosted environment that is not an option.

v0.10.0 now includes an option to combine database storage with file storage, so that any files bigger than a configuration value will be stored in the file system instead of in the database (so the database is only used to keep track of references to the big files). Or you can use my session state based alternative, which uses files to store all uploads.


21/8: Rewritten to be fully MS Ajax compatible

The demo now starts with the page in "view" mode, and the control first appears after a partial postback, and there is now two upload controls on the same page, just to demonstrate that it now integrates fully into the hardest possible partial postback cases!

During the rewrite I also removed display of the size of uploaded files, except when the upload fails. Basically, users don't need that extra piece of space-taking information - the progress percentage count is enough. That also hides the fact that uploaded files are resized on the server, so instead of making the user wonder why his image is suddenly smaller, we simply don't give him any reason to wonder or doubt what is happening.


New legacy mode in v0.9.9

The legacy mode works fine when users uploads the right kind of files and when they are not so big that the server (IIS) rejects them.

The trouble comes with regards to error messages for all the incorrect cases - the server code will do the same rejecting and security verification as for normal uploads, but there is not yet any JavaScript checking or warnings or error messages to inform the user what was wrong with his upload.

In other words: It is useable, but it need some more work to be good.


Preventing premature postback in v0.10.0

The JavaScript already got a popup that warns if the user tries to change page in the middle of an upload, but it did not catch the MS-Ajax partial postback, so I have added new code to the JavaScript to prevent partial postbacks while files are being uploaded. The user will instead see a popup message telling him to wait until the upload is finished.


New bugs found on Android 2.1 and the Chrome "no file chosen" popup

During march I have been doing user tests on two new websites where I am using my upload control, and I am sorry to say that I found two additional bugs:

First older Android phones (earlier than 2.3) seams not to support the new file selection method, so I will have to extend the legacy mode to cover those older models too, and a new set of tests for those older versions.

Secondly, while the browser's own ugly file upload control is correctly invisible in Chrome, Chrome now have a popup hint saying "no file chosen" when hovering over the invisible control - which made a test user very confused, since he just chosed a file, and instead of seeing it in the list below the button, his attention was caught by the popup... Fortunately it was easily fixed by adding the button text as a title attribute to the input tag - then Chrome displays that instead of it's own incorrect text when hovering.

The above fixes are now released as part of version 1.0.0.


The first feature complete version 1.0.0!

Yes, finally!

I discovered that Valum's JavaScript already had a mechanism for showing error messages from server side, which was just not used by the .NET code. So I added my own mechanism for all the server code to pass nice user-friendly error messages back to display client side. And then I added similar code to the legacy mode to also display the same error messages.

So for example if a user uploads an empty file, there will now come a correct error message back from the server. Similarly if the filename is not allowed due to security checks, the user will be asked to rename the file and try again.

Note that if you use the debug-version in legacy mode you will also see the exact .NET exception message, with more details about the check that failed (so obviously you should not use the debug-compilation in a production environment).



I will not be surprised if user tests reveals more odd browser bugs, especially on older mobile phones... At least in my own experience with software releases, I have always thought that version 1.0.0 of something means that the bugs have not yet been found!

And definitely there will be a follow up release with more translations.

But for now I will celebrate the milestone, and on Monday the 19/3 I'll start putting the updated version through testing for release in my production environments.

Allan K. Nielsen, Kindbergs Program Udvikling
Tweet This