editing/pasteboard/paste-text-006.html and fast/repaint/selection-clear.html started failing after r96257. It seems like we're not doing repainting right.
http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=fast%2Frepaint%2Fselection-clear.html%2Cediting%2Fpasteboard%2Fpaste-text-006.html
There's image change for editing/pasteboard/paste-text-006.html: http://build.webkit.org/results/Chromium%20Linux%20Release%20(Tests)/r96297%20(24051)/editing/pasteboard/paste-text-006-diffs.html And there's image change for fast/repaint/selection-clear.html: http://build.webkit.org/results/Chromium%20Linux%20Release%20(Tests)/r96296%20(24050)/fast/repaint/selection-clear-diffs.html
I've spent some time investigating this issue but all I can say is that there's very weird rendering bug here.
FWIW, fast/repaint/selection-clear.html isn't interesting. We probably just need to fix the test. LayoutTests/editing/pasteboard/paste-text-006.html is far more interesting. The actual result looks as if we selected the third line even though DOM selection never touch that line.
selection-clear.html works on qt port. paste-text-006.html has the same problem with 4th line rendered as selected. I'm in the process of installing 64bit linux since my debug build runs out of memory when linking. Without it I can only debug with printfs - hard for an issue like this one.
(In reply to comment #4) > LayoutTests/editing/pasteboard/paste-text-006.html is far more interesting. The actual result looks as if we selected the third line even though DOM selection never touch that line. Interesting! What's the selectionState on the InlineTextBoxes of that line?
LayoutTests/editing/pasteboard/paste-text-006.html was fixed by the patch for the bug 69377.
I'm looking at fast/repaint/selection-clear.html but I don't quite understand what the test is trying to test here because new behavior seems correct. http://trac.webkit.org/browser/trunk/LayoutTests/fast/repaint/selection-clear.html We have <div id="root" style="width: 100px; line-height: 100px;"> <div id="firstLine">FAIL: Test did not run</div><br> </div> and set up selection by getSelection().setBaseAndExtent(firstLine, 0, root.lastChild, 0); The actual test is firstLine.appendChild(document.createTextNode("\u00a0")); firstLine.removeChild(firstLine.firstChild); But the thing is, after the first text node (the one that contains "FAIL: Test did not run") is removed, the selection is adjusted to be from (#firstLine, 0) to (br, 0) and should still be rendered.
(In reply to comment #8) > But the thing is, after the first text node (the one that contains "FAIL: Test did not run") is removed, the selection is adjusted to be from (#firstLine, 0) to (br, 0) and should still be rendered. Correction: from (#firstLine, 0) to (br.nextSibling, 0)
Created attachment 109994 [details] fixes the test
Created attachment 110001 [details] revert WebCore change
Comment on attachment 110001 [details] revert WebCore change View in context: https://bugs.webkit.org/attachment.cgi?id=110001&action=review > LayoutTests/fast/repaint/selection-clear.html:28 > + Extra lines at the end of the file.
Comment on attachment 110001 [details] revert WebCore change Clearing flags on attachment: 110001 Committed r96963: <http://trac.webkit.org/changeset/96963>
All reviewed patches have been landed. Closing bug.