Bug 201645 – [GTK] Text areas render wrongly after using backspace or delete key on a blank line

• Component: WebKitGTK
• Status: NEW

[Ting-Wei Lan]

It is probably a regression of WebKitGTK 2.25.92.

To test the problem, open a web page with a text area. The text area should already have text and include at least a blank line. For example, you can test it with a HTML file with the element:

<textarea>
123
456

789
</textarea>

Don't test it by typing the text into a blank text area. The bug only occurs when it operates on existing text.

To reproduce the bug with backspace key:
1. Move the cursor to the right of 6.
2. Press backspace 3 times. It shows '123', two blank lines, '789'.
3. Press backspace again. It still shows '123', two blank lines, '789'.

This is wrong because the last backspace should delete a blank line, so the correct result should be '123', one blank line, '789'. The cursor is also partially 'locked' after pressing the last backspace. You can't move the cursor to the '789' line with keyboard. Pressing down arrow key does nothing.

To reproduce the bug with delete key:
1. Move the cursor to the left of 4.
2. Press delete 3 times. It shows '123', two blank lines, '789'.
3. Press delete again. It still shows '123', two blank lines, '789'.
4. Press delete again. It shows '123' and '789' with no blank line between them.

Results of step 2 and step 4 are correct, but the result of step 3 isn't. WebKit seems to maintain the text in the memory correctly, but it renders the text wrongly.

[Carlos Garcia Campos]

2ebcc2bac3010714ac6ebbc4397187b5e355d052 is the first bad commit
commit 2ebcc2bac3010714ac6ebbc4397187b5e355d052
Author: antti
Date:   Tue Aug 27 19:29:53 2019 +0000

    InlineTextBox::end() should return first-past-end offset
    https://bugs.webkit.org/show_bug.cgi?id=201181
    
    Reviewed by Zalan Bujtas.
    
    It currently points to the last character, except for empty text boxes.
    This is awkward in itself and also inconsistent, as we use first-past-end offset everywhere else.
    
    * dom/Position.cpp:
    (WebCore::Position::downstream const):
    
    Add a check for zero length case to avoid changing behavior.
    
    * layout/Verification.cpp:
    (WebCore::Layout::checkForMatchingTextRuns):
    (WebCore::Layout::outputMismatchingComplexLineInformationIfNeeded):
    * rendering/InlineFlowBox.cpp:
    (WebCore::InlineFlowBox::placeBoxRangeInInlineDirection):
    * rendering/InlineTextBox.cpp:
    (WebCore::InlineTextBox::paint):
    (WebCore::InlineTextBox::calculateDocumentMarkerBounds const):
    (WebCore::InlineTextBox::collectMarkedTextsForDocumentMarkers const):
    (WebCore::InlineTextBox::paintCompositionUnderlines const):
    (WebCore::InlineTextBox::paintCompositionUnderline const):
    * rendering/InlineTextBox.h:
    (WebCore::InlineTextBox::end const):
    
    end = start + len
    
    * rendering/RenderText.cpp:
    (WebCore::RenderText::setTextWithOffset):
    * rendering/RenderTextLineBoxes.cpp:
    (WebCore::localQuadForTextBox):
    (WebCore::RenderTextLineBoxes::absoluteRectsForRange const):
    (WebCore::RenderTextLineBoxes::absoluteQuadsForRange const):
    (WebCore::RenderTextLineBoxes::dirtyRange):
    
    Here the incoming 'end' used linebox style too, move that to the new definition too.
    
    
    git-svn-id: http://svn.webkit.org/repository/webkit/trunk@249160 268f45cc-cd09-0410-ab3c-d52691b4dbfc

:040000 040000 e110aeb63d19f3d9cf6474087cde263175ea43b6 69079a172fbc33fdabe32f37c9096555324b23dd M	Source

[Carlos Garcia Campos]

Ping. I reverted this in WPE and GTK stable branch, but we need to fix it in trunk.