milliAmp

Firefox 3 was launched this morning (5am NZ time). Mozilla Foundation have made a huge marketing effort to the point of setting a world record for the most downloaded software in 24 hours. Now, you’d expect, with a market share just shy of 20% of the global web browser market share and that kind of marketing, you would need some serious distribution technology.

Mozilla.com web traffic is pushing well over 2 Gigabits a second of just pure HTTP traffic. That is in addition to the 13 Gigabits a second or so of download traffic. We are still at around 14,000 download/minute and mozilla.com is responding well! Go Mozilla community and IT team! schrep – June 17th, 2008

Considering the numerous reports of the Mozilla.com website being down for at least the first hour of the record attempt, lloks like something in the middle couldn’t quite handle the load. At 15Gb/s that is close enough to 2GB/s, that is fairly large.

The official counter at SpreadFirefox.com shows 2,135,640 as at midday here, only 7 hours in. Either their counter is off or things have calmed considerably. If they were still blasting data out at 2GB/s the counter would be closer to 7 million by now.

I’m not going to go in to the features of Firefox 3 too much but for Mac Firefox junkies, it is a massive update. The interface is now using native widgets and is much faster. It also brings Firefox back into the running with Safari and Opera again in terms of standards support.

If you download it today, from http://getfirefox.com you’ll help Mozilla set a world record, the servers seem to be coping now so it downloads quite quickly however the Mac version weighs in just over 17MB which is on the steep side.

I was debugging a client-side heavy application today in IE7 and ran up against a very weird bug. Anyway, even with the Microsoft Script debugger, it took me a couple of hours to trace down the cause of this one bug.

The system has a page which works similarly to Apple Mac OS X’s Finder windows in Column View. In IE7, I was having a problem where all the children of a node inside a table cell where being removed from the DOM when I removed the table cell itself. If you think this sounds normal, let me explain.

In Javascript, DOM Elements exist as Javascript objects and can be attached into a document at any point, they do not have to be a document, they can exist solely as fragments. The normal DOM ‘removeChild’ method does exactly this; it detaches the child from the parentNode but if there are any references to the DOM element in javascript-land, it does not get deleted (or garbage collected to be more precise). This means you can reattach the node somewhere else after some processing.

Safari, Firefox and Opera appear to do this with the deleteCell method of a ‘table’ as well but Internet Explorer appears to do something different. There is a little bit of speculation here as I haven’t created a minimal test case of this bug yet but it appear that IE detaches all the DOM Nodes recursively beneath the cell it deleted. This doesn’t appear in the MSDN documentation so I’m not sure quite what is happening, am I experiencing a bug caused by something else maybe.

How would that be useful!? I can’t see a purpose for it but whatever.

My fix was to remove all the child nodes of the ‘td’ element using removeChild first, then delete the cell. That meant the elements that were in the cell before hand still existed if there were any references to them, which there were.

I has been an awfully long time since I last posted here. Many things I could’ve written about, maybe I will in the next few weeks.

Anyway, this post is about Windows Vista. More specifically, installing Windows Vista Business (64bit) onto a Macbook Pro (Santa Rosa).

The Apple Bootcamp drivers that came with my laptop don’t support Windows Vista 64bit so I had to do some digging around to find the drivers that worked and get everything running smoothly.

This information is out there on the web but I found some of the instructions on exactly which driver to choose a little had to understand. Below is a list of the drivers I used to get Vista Business 64bit working on this Macbook Pro.

Video

Hardware: nVIDIA 8600M GT with 256MB RAM
Drivers: nVIDIA ForceWare X 167.62

Audio

Drivers: RealTek R190

Keyboard/Fan

Drivers: Input Remapper 1.0.04
NB: Screen backlight control is not supported on the nVIDIA card yet

Wireless

Drivers: Atheros v7.6.0.83

Ethernet

Drivers: Marvel Yukon v10.57.3.3

This information is mainly from two sources:

http://rumblingsfromdeveloper.blogspot.com/2007/12/macbook-pro-and-vista-64bit-x64-issues.html

http://forum.notebookreview.com/showthread.php?t=149395

With these drivers I got a Windows Experience Index of 4.9
Processor: 5.2
RAM: 4.9
Desktop Graphics: 5.9
Gaming Graphics: 5.5
Primary Hard Disk: 4.9

Steve Jobs has issued a Hot News article detailing Apple’s stance on DRM and it’s future. I’m going to go so far as to say he has laid down a challenge in full public view to the big 4 Music Distribution Companies. However I can see that his account serves only to appease the public’s wrath due to Apple not licensing it’s FairPlay DRM technology to other companies, I can’t see the big wigs in the music world even reading the article, let alone uttering more than a chuckle.

http://www.apple.com/hotnews/thoughtsonmusic/

I spent a huge part of today trying to determine the cause of a major Internet Explorer performance and rendering regression in a Web Application I'm developing. The reason it was such a bitch to find was because so much code had changed since the last time I had done a proper test in IE6. This was in code which I didn't expect to cause rendering issues, performance issues maybe, but those could have been dealt with.

So, I went through carefully ripping apart the project, disabling stylesheets, removing images, removing individual styles to figure out what was going on. About a hour later I hadn't got very far. I had determined that every¹ browser was fine except IE6.

In frustration, I turned to Google. Trying to find pages describing huge black areas rendering over the page while using Scriptaculous Sortables got my nowhere so I tried searching for causes of huge black rendering artefacts in IE in general... nothing.

I turn back to trying to make a minimal test case. I ended up removing an image that was inside each Sortable item and suddenly the rendering problem went away and the performance jumped up significantly. Anyway, some dilly-dallying around and it turns out it was the javascript I'd written causing problems at all. It was the IE6 CSS Alpha PNG hack which was causing all the problems (which was working fine without performance issues the last time I tested this site in IE6).

It is indeed common knowledge among web developers that IE6 does not support transparency on 24-bit+Alpha PNG images. The alpha channel is rendered [usually] in a baby blue colour instead of being see-through.

To remedy this I was using the fastest hack around the issue that I have found and it involves pasting 5 lines in the CSS file for a site and bingo. I didn't make this hack but here's how it works. It uses the proprietary filter CSS attribute combined with the DirectX ActiveX control to draw the PNG, to target only PNGs and the also proprietary CSS extension 'expression' which uses JScript to compute values. I haven't had a problem with this hack yet, it doesn't handle CSS background images but I haven't needed it to yet.

This combined with the addition of a PNG on each individual Sortable Item caused the poor DirectX Transform to basically crap itself and render parts of the window black. Very black.

Blah.

What a waste of many hours of my day.

Honestly though, this rendering bug caused a few 'wow' moments from people in my office when they saw what IE was displaying on the screen and how it took roughly 20 seconds and 100% CPU to drag one single item between two lists. I'll have a screen-shot of this up in the next few days.