The flake was reproducible by running the entire LibWeb test suite over
and over again with sanitizers enabled. By making the test async and run
at window `load` time instead of document `DOMContentLoaded` time, I've
not been able to reproduce the issue locally.
Ideally I was able to find the underlying cause for this bug, but for
now I'd rather run this regression test.
We generated `PaintableFragment`s with a start and length represented in
UTF-8 byte offsets, but failed to consider that the offsets in a
`DOM::Range` are actually expressed in UTF-16 code units.
This is a bit of a mess: almost all web specs use UTF-16 code units as
the unit for indexing into text nodes, but we almost exclusively use
UTF-8 in our code base. Arguably the best thing would for us to use
UTF-16 everywhere as well: it prevents these mismatches in our
implementations for the price of a bit more memory usage - and even that
could potentially be optimized for.
But for now, try to do the correct thing and lazily allocate UTF-16 data
in a `PaintableFragment` whenever we need to index into it or if we're
asked to determine the code unit offset of a pixel position.
