Interesting Browser Engine Bugs, Part 3: <select> Tags Crash Chrome
Part 3 on yet another browser bug.

August 16th, 2024
  1. Part 1: Test Timeouts
  2. Part 2: On Video Conferencing
  3. Part 3: <select> Tags Crash Chrome (You’re here!)

I hope you enjoyed (and possibly sympathized) with the bugs in this series. Somehow, I’m the one that manages to find and diagnose a lot of these and they were interesting to debug.

This last bug really wasn’t totally out of our control, but a change to the browser implementation of <select> tags uncovered a severe performance problem in our application. This is also the first bug that caused real problems for end users, and required us to put in a code change to mitigate some adverse affects resulting from the issue.

chromium: Tab hangs/crashes on select with large number of options

Everybody is familiar with <select> tags. They’re ubiquitous in HTML templates.

Have you ever though about how browsers render them? Or how about if you try to force an insane number of options into a single <select>? What if you gave a browser something like…

<select>
  <option value="1">Super important</option>
  <option value="2">Definitely need this</option>
  <option value="3">Can't live without</option>

  <!-- roughly 10 thousand <option> tags later -->

  <option value="9999">Must have</option>
  <option value="10000">THIS SUSTAINS MY EXISTENCE</option>
</select>

What would happen? It’s not really a rhetorical question. In our case, Chrome happily renders this – and fairly quickly! At least for a while.

On May 16, 2024, a bug was posted to the chromium issue tracker: Tab hangs/crashes on select with large numbers of options

If you’ve followed the series, you can probably guess what’s next. This bug was introduced into a version of chromium (125.x) and packaged into Chrome, which was then pushed out by our managed IT system at a later date. Thus, our first introduction to the issue did not directly correlate with the chromium bug tracker.

We received reports starting May 21 that pages were “slow” to load. We looked at our internal application performance monitoring dashboards and saw no degradation, a surprising revelation that in hindsight pointed to a browser issue. Network traffic was fine (which would have been caught by APM), but at the time we did not collect page load times, browser paint duration, etc. to be able to detect it (we have since remedied this).

It took a while to narrow the common denominator to Chrome 125.x. When we did, the problem was very obvious. “Slow” page loads, in my professional opinion, were vastly understating the problem – I managed to crash Brave (also built on chromium) on a few pages.

Further investigation into the issue revealed problems on only a handful of pages. These did contain suspect <select> tags, so we spent a while figuring out what was populating them.

It turns out that the affected pages contained <select> tags populated with tens of thousands of options. These were used to filter through a list of available users.

But… that list of users was never filtered down. It was literally a list of 10,000+ past and present employees, but never accounted for employees that were no longer with the company, didn’t have access to the tool, or were otherwise irrelevant to the selection.

Oops.

We added the appropriate filters to mitigate the problem, IT pushed out the next stable version of Chrome a few days later, and the problems (both the browser bug and missing user filters!) were resolved.

This bug was interesting because as web developers, we like to abstract away the platform (browser) that the front end runs on and assume that it’s a constant. However, as was the case with this issue, the browser isn’t static, and changes to it can and do have performance effects on your application, even if you haven’t changed the code.

That’s all for now. Thanks for reading!