Firefox, LinkButtons, and the Panel.DefaultButton: a (Prototype) fix

Recently I’ve stepped away from the MonoRail world to work on a project that uses ASP.Net WebForms. It didn’t take long before I found an annoying problem. (Actually I found many annoying problems, but I’ll focus on one here.)

The <ASP:Panel> control has a DefaultButton property which, according to the documentation, "Gets or sets the identifier for the default button that is contained in the Panel control." In other words:

Use the DefaultButton property to indicate which button gets clicked when the Panel control has focus and the user presses the ENTER key.

It works perfectly, if you’re not using a LinkButton control. Actually, that’s not true; if you use a LinkButton control and Internet Explorer, it works fine. It just doesn’t work in Firefox. Why?

Dmytro Shteflyuk outlines why in his blog post, Using Panel.DefaultButton property with LinkButton control in ASP.Net. Apparently, it’s an issue with the JavaScript code that Microsoft generates, which expects a click() method on the anchor (i.e. LinkButton). Firefox doesn’t have such an event for anchors — at least, not by default.

Dmytro outlines a fix which requires you to injext some JavaScript for each button. I prefer a simpler approach using CSS selectors, so I wrote the following script (Prototype required) to do it. Simply add this script to your web page, add the CSS class "button" to each LinkButton control, and press ENTER on your Firefox forms.

function prepareLinkButtonClicks()
	$$('a.button').each(function(tag) {
		if (tag && typeof( == 'undefined')) { = function() { 
				var result = true;
				if (tag.onclick) result = tag.onclick();
				if (typeof(result) == 'undefined' || result) {
Event.observe(window, 'load', prepareLinkButtonClicks);

Firefox truncates long tables when printing

I stumbled across a weird bug in Firefox today — a bug that apparently has been around for quite some time, as it was originally reported on 2005-05-20.

If you have a table which is longer than the page, in certain situations, when printing the page, a page break is forced before the table, and only the first visible page of the table prints, with the rest of the content disappearing altogether.

The original bug report describes it rather well:

… The first [page] contains material preceding the table, the second [page] contains most but not all of the table, and the third [page] is empty.

The bug was confirmed on 2005-06-19, but no fixes followed. On 2006-07-31 a user alluded to a workaround:

From further tests, you can see that the bug happens when BOTH THE FOLLOWING
CONDITIONS are respected:

A) The page contains an <h1> title
B) The table in the page contains a <caption>caption

The web page in my project which was exhibiting this bug had an h1 at the top of the page and a caption at the top of the offending table. Removing the caption from the markup fixed the problem, as did applying the display:none style to the caption.

It’s a frustrating bug, but once you know the workaround, it’s easy to deal with.