201645 2019-09-10 08:55:13 -0700 [GTK] Text areas render wrongly after using backspace or delete key on a blank line 2019-09-27 05:09:34 -0700 1 1 1 Unclassified WebKit WebKitGTK WebKit Local Build Unspecified Unspecified NEW https://bugs.webkit.org/show_bug.cgi?id=201181 P2 Normal --- 1 lantw44 webkit-unassigned bugs-noreply cgarcia koivisto zalan oldest_to_newest 1569554 0 lantw44 2019-09-10 08:55:13 -0700 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. 1571091 1 cgarcia 2019-09-16 07:39:54 -0700 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 1574781 2 cgarcia 2019-09-27 05:09:34 -0700 Ping. I reverted this in WPE and GTK stable branch, but we need to fix it in trunk.