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.