I’ve been pretty annoyed about the fact that FireFox ignores the width property of the ASP.NET FileUpload control. It doesn’t matter if you set it by CSS or even in JavaScript, Firefox always ignores it and that results in a crippled layout since you have no control over the width of the upload input field. This actually has nothing to do with the FileUpload control, but with the rendered output of that control, which is just a standard <input type="file"...> field.

Here the width is set to 400px. The FileUpload control renders the Width attribute to the correct CSS style value of 400px at runtime.

[code:html]

<asp:FileUpload runat="server" ID="txtUpload" Width="400" />

[/code]

But as mentioned, Firefox totally ignores that. Then I remembered a forum thread I read some years ago about a size attribute. The only thing I could find was this list of available HTML attributes, but I gave it a try.

This is what I ended up with. The size attribute actually works in Firefox and IE ignores it, but adheres to the Width attribute instead.

[code:html]

<asp:FileUpload runat="server" ID="txtUpload" Width="400" size="50" />

[/code]

The size attribute determines the number of characters should be visible and then adjusts the width accordingly. It is not the same as setting a maximum length of the file name, so it doesn’t break anything.

You should think that since a size of 50 generates the same width as 400px that you could always just divide the width in pixels with 8 to find the equivalent size. That is not the case. You have to manually adjust every time until you find the right size value that matches the pixel width.

Don’t you just love these kinds of obscure browser differences?

Today I was working on a web page that performs an AJAX call on unload, so when a person navigates away from the page, the AJAX call is triggered. The goal was to register that the visitor navigated away from the page so just a one-way call was needed.

I started out using a simple ASP.NET client callback and it worked – or so I thought. When the next page on the same website is loaded, a JavaScript error occurred because the __pendingcallback variable was null.

Then I made the callback asynchronous instead of synchronous but it didn’t help. Then a colleague suggested that I should use an ASP.NET AJAX script service call instead. That didn’t help. A JavaScript error still occurred though it was a different one but caused by the same issue.

So I started doing what I should have done from the beginning – do it old school. It’s faster, more reliable, uses GET, light weight and completely cross-browser supported. I created an HttpHandler that took a few URL parameters. I could have used the same page but for this scenario a handler was more appropriate and they are always faster.

Then I added this piece of code in the unload event handler in JavaScript:

[code:html]

<script type="text/javascript">
function UnLoadHandler()
{
  var img = new Image();
  img.src = "/handler.ashx?id=1234";
}

window.onunload = UnLoadHandler;
</script>

[/code]

The UnLoadHandler() method performs a GET request to the handler by preloading it into an Image object. This is of course not AJAX according to the definition, but it is asynchronous and uses JavaScript. I guess that makes it AJ.