Commit Graph

5 Commits

Author SHA1 Message Date
Jelle Raaijmakers
9e9db9a9dd LibWeb: Store correct text offsets in PaintableFragment
Previously, we were collapsing whitespace in Layout::TextNode and then
passed the resulting string for further processing through ChunkIterator
-> InlineLevelIterator -> InlineFormattingContext -> LineBuilder ->
LineBoxFragment -> PaintableFragment. Our painting tree is where we deal
with things like range offsets into the underlying text nodes, but since
we modified the original string, the offsets were wrong.

This changes the way we generate fragments:

  * Layout::TextNode no longer collapses whitespace as part of its
    stored "text for rendering", but moves this logic to ChunkIterator
    which splits up this text into separate views whenever whitespace
    needs to be collapsed.

  * Layout::LineBox now only extends the last fragment if its end offset
    is equal to the new fragment's start offset. Otherwise, there's a
    gap caused by collapsing whitespace and we need to generate a
    separate fragment for that in order to have a correct start offset.

Some tests need new baselines because of the fixed start offsets.

Fixes #566.
2025-09-12 15:34:09 -04:00
Jelle Raaijmakers
dbbdf2cebc LibWeb: Improve caret positioning behavior inside fragments
When clicking on a glyph or starting a selection on it, we would use the
glyph's offset/index as the position which represents the left side of
the glyph, or the position between the glyph and the glyph before it.

Instead of looking at which glyph is under the mouse pointer, look at
which glyph boundary is closer. Now, if you click to the right of a
glyph (but still on that glyph), it correctly selects the next glyph's
offset as the position.
2025-06-13 15:08:26 +02:00
Jelle Raaijmakers
29f1648bc5 LibWeb: Do not override whitespace handling for editable elements
This condition no longer seems to be necessary for anything, and it
caused newlines to not render correctly in editable nodes.
2025-05-16 12:08:29 +01:00
Timothy Flynn
bf668696de LibWeb+WebContent: Do not include DOM HTML in text test expectations
For example, in the following abbreviated test HTML:

    <span>some text</span>
    <script>println("whf")</script>

We would have to craft the expectation file to include the "some text"
segment, usually with some leading whitespace. This is a bit annoying,
and makes it difficult to manually craft expectation files.

So instead of comparing the expectation against the entire DOM inner
text, we now send the inner text of just the <pre> element containing
the test output when we invoke `internals.signalTextTestIsDone`.
2024-10-03 07:07:28 -04:00
Aliaksandr Kalenik
cd7b5b18e4 LibWeb: Emit "selectionchange" event on document 2024-02-25 10:17:25 +01:00