Both sides were white

The bug report was four words and a link. The fix was deployed at 09:43 UTC.

A chess board where both armies are drawn in the same pale cream outline, so the two sides are indistinguishable

“both sides are white in this” — and a link to an opening page. That was the whole report, and it was enough. The board above is a reconstruction: we never captured the original, so we rebuilt it from the code that caused it. That is what the page looked like on the phone it was sent from, and there is no way to play a position you cannot read.

We never did reproduce it. Every machine we opened it on drew the same page correctly — dark pieces at the top, light at the bottom — so we had a report of something none of us could see:

The same opening page on our own machine, rendering correctly with clearly distinct dark and light pieces
The exact link from the report, at the same width, on our machine. It is fine. This is why nobody here had caught it.

Finding the cause took about ten minutes, and it came from reading how the board is built rather than from staring at it.

Chess pieces are text

Our boards were drawing pieces as text characters — the same kind of character as a letter or a comma. There are Unicode characters for chess pieces, and they are a tempting shortcut, because a board becomes eight rows of typing. The catch is that a character has no appearance of its own. Your device picks a font and the font decides what it looks like.

Worse, we were only shipping one set of them. The white pieces were the black characters, filled cream and outlined dark — a trick that produces a convincing white army as long as the font draws those characters as solid shapes. Plenty of fonts do. The one that phone reached for did not, and the moment the shape came out hollow the fill had nothing to fill. Both armies, the same pale outline.

It survived because it renders perfectly on the machines we build on, and we had nothing checking otherwise. We still do not know which font that phone reached for. The fix does not depend on knowing, but we would rather have the answer than not.

What we changed

Every board in Eloist now draws its own pieces as vector shapes we control, so the two sides are ours to define rather than your device's. Same page, same width, now:

The same board after the fix, with clearly distinct dark and light pieces on a wood-toned board
Nothing here is a font any more. The pieces also follow whichever board theme you picked, which the old ones never did.

Eight boards had the same flaw. Only one had been reported. We wrote a check that fails the build if any board ever renders pieces as text again, and running it turned up three more we had not been told about — including the promotion picker, which is a genuinely bad place to be unable to tell a white queen from a black one.

The clock

The commit landed at 09:41:02 UTC and the deployment went out at 09:43:18. Between the report and the commit: reproducing it at phone width, finding the cause, and rewriting eight boards. We added the build check in the same commit, so another text-rendered board cannot reach production.

Open the explorer →