[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