Forcing users to choose a browser other than Internet Explorer doesn’t help them

In the news this morning, I stumbled across an article, EU: 100 million Microsoft users to choose browser. Reading this, there were a few instances of questionable logic.

The first instance (emphasis added):

Microsoft is starting this month to send updates to Windows computers in Europe so that when computer users log on, they will see a pop-up screen asking them to pick one or more of 12 free Web browsers to download and install, including Microsoft.

Microsoft is allowing users to choose one of more than 12 free web browsers, because the EU didn’t like Microsoft bundling its own free web browser into Windows. Call me strange, but punishing a company to give something away for free because it blocks out other companies from giving their own products away for free strikes me as odd.

The second instance (emphasis added):

The EU’s executive commission said giving consumers the chance to try an alternative to Microsoft’s Internet Explorer browser that comes with the widely used Windows operating system would “bring more competition and innovation in this important area.”

Wait, didn’t we just read that there are “more than 12 free web browsers”? That doesn’t sound like lack of competition and innovation to me at all. How many industries offer a choice of over a dozen free items? None that I can think of.

web-browser-market-shareI am aware of Microsoft’s predatory practices in the web browser arena, particularly related to the browser wars between them and Netscape. Microsoft muscled out Netscape by giving away its browser for free, something Netscape didn’t do until early 1998. Isn’t that a good thing for consumers? Further, client software (such as Navigator) was a small portion of Netscape’s revenues, and at the time, “Netscape has successfully shifted its business over the past year toward enterprise software sales and to revenues from its Web site business, and away from standalone client revenues” (source: Mitchell’s Blog). If Netscape was successful in transitioning away from a client product, but ultimately failed in the enterprise marketplace, why is Microsoft being punished?

In the end, Microsoft was penalized for providing a product for free – and forcing the market leader to ultimately transform their business (“successfully”) and offer their own (similar) product for free. The fact is, Microsoft’s efforts were largely responsible for the explosion of free web browser alternatives – yet the EU still feels a need to punish them because there is “[not enough] competition and innovation in this area,” as they say.

Final point: let’s not mention the pain and suffering that novice users will have after installing other browsers, wondering where their bookmarks went, and wondering why they are being prompted to (re-)install Adobe Flash so they can play YouTube videos.

Some things are better left alone. This is one of them.

Live search’s extra spaces (only for Firefox, of course)

Go to http://www.asp.net and do a search to see a nifty AJAXy popup search results box, powered by Live Search and including some advertising (which I deliberately grayed out below). Look closely, and you’ll see the URLs in the search results (circled in red) have spaces where spaces just shouldn’t be. No surprise, this happens Firefox but not in Internet Explorer.

About the only thing missing is a "Best viewed with Internet Explorer" logo, circa 1998. This really inspires me to click the "Get my own Search Box!" for my site — I’d just love this bug to be reflected in my own work, too.

image

Improving TableKit’s sort performance in IE7

I noticed that TableKit‘s sort performance using IE7 grew progressively worse as tables grew in size (rows, not columns). I found the source of the problem and put in a simple fix to it. With the below change, sorting in IE7 is nearly as fast as in Firefox — that is, nearly instantaneous.

At line 322 (TableKit 1.2.1), comment the line as shown, and add the line noted.

        var tb = table.tBodies[0];
        var tkr = TableKit.Rows;
        rows.each(function(r,i) {
            tb.appendChild(r);
            //tkr.addStripeClass(table,r,i); /* THIS LINE COMMENTED */
        });
        TableKit.Rows.stripe(table); /* THIS LINE ADDED */ 

The change shouldn’t break anything as the new code added is standard TableKit code.

Capturing function keys in web browsers

I have a web application that allows the user to press the F2 key to bring up a modal box search window (the modal box script is provided by ModalBox). Today, one of the users came to me and said that every time they press the ‘Q’ key in the search box, the modal box refreshes.

It turned out that pressing the ‘Q’ key did in fact refresh the modal box — but only in Firefox, not in Internet Explorer. Knowing that Mozilla and IE have slightly different JavaScript event capture techniques, I looked at the code I was using to capture the F2 keypress.

Event.observe(window, 'load', function() {
	Event.observe(
		document, 'keypress', function(event)
		{
			if (event.keyCode) 
				keycode=event.keyCode;
			else
				keycode=event.which;
			if (keycode==113)
				Modalbox.show('Search', '/search/quicksearch.rails', {width:360, height:90});
		}
	);
});

A little research and I found the problem: keyCode 113 is the ASCII code for the lower-case ‘q’. I needed to find a way to capture the event when the function key 113 was pressed, not the ‘q’ key 113.

The solution was to use the event.charCode exposed in Firefox. This is undefined in IE, but in Firefox it equals zero when a function key is pressed. A little revision to the JavaScript code resulted in the following (note the difference in the line that contains (keycode==113).

Event.observe(window, 'load', function() {
	Event.observe(
		document, 'keypress', function(event)
		{
			if (event.keyCode) 
				keycode=event.keyCode;
			else
				keycode=event.which;
			if (keycode==113 && (event.charCode ? event.charCode : 0) == 0)
				Modalbox.show('Search', '/search/quicksearch.rails', {width:360, height:90});
		}
	);
});

Problem solved.

IE7 reverses table rows during Insertion.After

I found yet another interesting bug in IE7, related to using Prototype‘s Insertion.After command to insert additional table rows into an existing table. Apparently, IE7 will reverse the order of the table rows being inserted. As a proof of concept, I’ve set up an ie7 table insert bug test page to prove my point.

Here’s how to duplicate this bug.

  1. Create a new web page (we’ll call it test.htm).
  2. Create a <table> and add a few rows.
  3. Give one row a specific id (such as id="insertAfterThis").
  4. Create a separate web page (call it testdata.htm) with more table rows — just the <tr>...</tr>, nothing else.
  5. Add the following JavaScript to run after the window loads:
    new Ajax.Request('testdata.htm', { method:'get', onSuccess:function(transport) { new Insertion.After('insertAfterThis', transport.responseText); } });
  6. Load the test.htm page in Firefox, and see how the rows are inserted in the order they exist in the testdata.htm file.
  7. Load the test.htm page in IE, and see how the order of the rows is reversed.

It’s quite a frustrating bug, because there’s apparently only two ways to work around it:

  1. Figure out a way to add markup that forces IE to add the rows correctly.
    OR
  2. Have IE receive the table rows from your Ajax call in reverse order (so it’ll reverse it again into the correct order).

Considering we’re not even sure if #1 is possible, it’s a very frustrating bug. Some may say it’s a bug with the Prototype library, but I doubt it, since Prototype is simply inserting text — it has no idea there’s a table involved. IE7 reveals yet another illogical bug.