[Webkit-unassigned] [Bug 201645] New: [GTK] Text areas render wrongly after using backspace or delete key on a blank line

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Sep 10 08:55:13 PDT 2019


https://bugs.webkit.org/show_bug.cgi?id=201645

            Bug ID: 201645
           Summary: [GTK] Text areas render wrongly after using backspace
                    or delete key on a blank line
           Product: WebKit
           Version: WebKit Local Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKitGTK
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: lantw44 at gmail.com
                CC: bugs-noreply at webkitgtk.org

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190910/b3de7ccc/attachment.html>


More information about the webkit-unassigned mailing list