The great thing about the web is that web pages from thirty years ago still work fine. So you can imagine how surprised I was when a new version of Chrome broke my client's web app in production.

Business as usual

The web app is a data visualization tool with a colourful d3 SVG map. Hovering over a country brings up a tooltip, and clicking a country brings up a larger panel with data. Although the application was originally developed in 2013, I took it over in 2022.

I was working on some changes to the web app a couple of weeks ago. I run Linux (Arch btw) so I always have the latest version of everything, including Chrome. I spun up the development site one day and suddenly the map tooltips and clicking stopped working.

Did I install something new that broke the interactions? Maybe one of my Chrome extensions was messing with something? I tried rebooting, as one does when they're out of ideas. Still didn't work.

I loaded up Firefox. Everything worked fine. I grabbed my mac and tested it out in Chrome. Everything worked fine there too. I sent off my changes for the day for my client to review, and they didn't say anything about it being broken.

I could have left it at that, but it didn't sit right with me. That evening I started digging into it more.

Classically debugging a hard bug

First thing I did was add console.log statements to the d3 event handlers.

I could see that the mouseenter and mouseleave events were working, but the mousemove and click handlers never fired. I tried remove the mouseenter and mouseleave handlers, and suddenly the mousemove and click started working again.

I put back the mouseenter and mouseleave and looked for something that could have been responsible. Then I found this suspicious line:

// bring it to the front and maintain full stroke
path.parentNode.appendChild(path);

I removed it and it started working again! But that line was written six years ago, before I ever worked on the app. Why would that be to blame? What changed?

It Is Never a Compiler Bug

There's a trope in programming that "it's never a compiler bug". As a web developer, we would say "it's never a browser bug". Well could it be this time?

I was running Chrome v144 so I found the release notes. It came out on January 13th, so the timing made sense.

I scrolled and skimmed and finally found something that sounded like it might be relevant:

Interoperable pointer and mouse boundary events after DOM changes

After an event target is removed from the DOM, the logical target of the pointer, as implied by the Pointer and Mouse boundary events (that is, over, out, enter, and leave events), should be the nearest ancestor still attached to the DOM.

This led me to find a bug filed for Chromium v144, Regression in Chrome 144: Moving event target in "mouseenter" handler breaks click+mouseleave events. It was a Chrome bug! The example code even matched mine almost exactly:

redSquare.parentNode.appendChild(redSquare);

It seems like this is a permanent change due to a refinement of the spec. It's apparently a feature-not-a-bug, called BoundaryEventDispatchTracksNodeRemoval, so it's probably never going to be fixed.

There's fortunately a suggestion in a comment of how to fix this on my end though:

if (elem.parentNode.lastChild !== elem) {
    elem.parentNode.appendChild(elem);
}

Makes total sense! I made the change, and everything was working just as it had been a couple of weeks earlier!

Always trust your gut

I'm going to resist blaming the browser next time I have a bug, but it's very interesting to be reminded that it can and does happen.

The important takeaway is that when I see something wrong on a client project, I'm not going to be able to rest until I figure out exactly why. I needed to be sure it was limited to my computer, because if it wasn't, the last thing I'd want is for my client to find out from one of their users.

I of course pushed the change that night and let my client know what had happened, and that the production site was already being affected. Fortunately, v144 hadn't been fully rolled out. Even as I write this, less than 4% of users are running v144. This also underscores the importance of developers testing using the newest versions.

As a developer, I always want to fix bugs before my client notices, and definitely before their users notice.

If you're not familiar, Lynx is the most basic web browser, found on Unix and Linux servers. There are no photos, just pure text, links and forms.

You're probably wondering why you would ever think about supporting a browser that's based in a console window. Does anyone actually browse the web from a bash shell?

Basically, here's the benefit: if you know it works in Lynx, you know it works everywhere. Lynx doesn't have JavaScript or CSS available, and there are no images. It doesn't get more limited than that.

And actually, a lot of the traffic to your site is viewing things in this HTML-only form. I'm talking about search-engine spiders, bots, and people stuck using text-only devices such as screen readers.

So run through your site with Lynx now and then. You will be able to see at a glance if there is enough hidden or alternate text on the page to be useful to search engines and the blind. You'll also be able to ensure that forms and functionality are available to absolutely everyone, even people browsing under Bash!

Update: I just discovered Seebot, a web app which lets you browse the web the same text-only way Lynx (and bots) do.

We thought this day would never come: Internet Explorer 8 now renders the "Acid2 Face" correctly in IE8 standards mode!

Apparently we can expect to see Internet Explorer 8 in at least Beta form in early 2008. According to the IE blog:

The key goal (for the Web Standards Project as well as many other groups and individuals) is interoperability. As a developer, I’d prefer to not have to write the same site multiple times for different browsers. Standards are a (critical!) means to this end, and we focus on the standards that will help actual, real-world interoperability the most.

Sounds like the IE team has finally seen the light! :)

Good news for all Windows-based web developers: Safari for Windows is now available (via).

Hopefully this means that we can make our web sites even more cross-browser (and hopefully doesn't just add another browser with its own quirky differences).

This week, I installed TredoSoft's Multiple IE package (via friendly bit). It's an installer for Internet Explorer standalone versions 3, 4.01, 5.01, 5.5 and 6. It's based on evolt's standalone versions, but packed up in a nice installer. It even fixes some problems with cookies and conditional comments.

Check it out, it's a great package to have installed, and makes it a lot easier and cleaner to get all the old IEs running on your system. (You're all testing your web sites in IE 3, aren't you???)

When the first beta of Internet Explorer 7 came out, the biggest complaint was that there was no easy way to have it run as a standalone browser. You're pretty much forced to upgrade your whole system to use it.

I took the plunge anyway, deciding I'd rather run IE7, but I ran into all sorts of situations where I really needed IE6 for debugging.

There are a lot of hacks and instructions for taking apart the IE7 beta so that you can run it standalone. I've decided that the extremely easier solution is to just install IE7, then download the standalone of IE6.

Now that the Release Candidate is out, you probably don't want IE6 to be your main browser anymore, right? So why not just have it around for the few times when you really need it?

I just heard about Swift (via Chris Messina). Swift is a port of WebKit for Windows. WebKit is the rendering engine behind Safari (in the same way Gecko is behind Firefox and Mozilla). So I figure, sweet! Safari for Windows!

I had some problems though. On one of my PCs, WebKit.dll couldn't be registered so the installation failed. Weird.

On my other PC, I got Swift installed no problem. I ran it and.. well.. let's just say it's clearly Alpha software. Not only is the user interface extremely bare minimum (you're not going to make this your default browser any time soon), the functionality is a bit iffy. For example, it crashed when I clicked a normal link.

Perhaps it will help you see how WebKit will render your page.. but I wouldn't rely on it. I had a password field go missing, and buttons are styled with CSS whereas I'm pretty sure they aren't in Safari.

It seems there is also a problem with JavaScript. JavaScript executes, sometimes, but I had a problem getting popups to launch, or to load my new Google ads. Okay, maybe you won't miss popups and ads, but what else will break?

I give massive kudos to WebKit and Chris Fuenty for putting this together. It's not there yet, but I can't wait until it is. Having a port of WebKit on Windows will help web developers without Macs immensely. Maybe one day Swift will even become a major player in the browser market.

This happened a few days ago, but I didn't think to blog about it until now for some reason: Opera 9 has been released. There are a lot of changes to it, the most notable (to me anyway) is the presence of Rich Text Editing, otherwise known as contentEditable or designMode. Click here for a demo and documentation. I've had a chance to play around with it and it works very well using existing code from Firefox and Internet Explorer. It seems there are some minor differences for really specific things, but overall I was suprised at how compatible it was right out of the box.

Now if only Safari's rich text editing could get this sophisticated...

There are other big changes that look great, but I won't bother listing them all here. Go take a look at the release notes for that.

When early versions of Internet Explorer 7 were released, it was clear that IE would now have a search toolbar like Firefox. It was also clear that this would default to use MSN, rather than the Firefox default of Google. Google freaked out and tried to sue Microsoft, but the Justice Department said it was OK and prevented Google from doing anything about it. Google's strategy was to continue to promote Firefox, as well as give instructions to IE 7 users on how to change their default search engine.

Now, Yahoo! has released a customized version of IE 7 beta which presets the homepage and search bar to Yahoo!. Rather than fight the beast, they've embraced it and made things even easier for people who still prefer Internet Explorer. Good move, Yahoo!.

Disclaimer: I only use Internet Explorer for testing. Firefox is definitely the way to go for day-to-day surfing.