Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-11-08 17:21:02 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Tests/LibWeb/Text/input/selection-over-multiple-code-units.html

20 lines
503 B
HTML
Raw Normal View History

LibWeb: Treat `DOM::Range` offsets as UTF-16 code unit offsets 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.
2025-06-12 13:19:52 +02:00
<!DOCTYPE html>
<script src="include.js"></script>
😭foobar😭
<script>
Tests: Unskip `selection-over-multiple-code-units.html` test 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.
2025-07-02 13:07:57 +02:00
asyncTest(done => {
window.addEventListener('load', () => {
internals.mouseDown(55, 20);
internals.movePointerTo(110, 20);
Tests: Force layout in test to prevent flakiness
2025-06-18 10:06:11 +02:00
Tests: Unskip `selection-over-multiple-code-units.html` test 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.
2025-07-02 13:07:57 +02:00
const activeRange = window.getSelection().getRangeAt(0);
printElement(activeRange.startContainer);
println(activeRange.startOffset);
printElement(activeRange.endContainer);
println(activeRange.endOffset);
LibWeb: Treat `DOM::Range` offsets as UTF-16 code unit offsets 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.
2025-06-12 13:19:52 +02:00
Tests: Unskip `selection-over-multiple-code-units.html` test 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.
2025-07-02 13:07:57 +02:00
done();
});
LibWeb: Treat `DOM::Range` offsets as UTF-16 code unit offsets 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.
2025-06-12 13:19:52 +02:00
});
</script>
Reference in a new issue Copy permalink