Bug 69060 – REGRESSION(r96257): fast/repaint/selection-clear.html fail

• Component: Layout and Rendering
• Status: RESOLVED FIXED

[Ryosuke Niwa]

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.

[Ryosuke Niwa]

http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=fast%2Frepaint%2Fselection-clear.html%2Cediting%2Fpasteboard%2Fpaste-text-006.html

[Ryosuke Niwa]

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

[Ryosuke Niwa]

I've spent some time investigating this issue but all I can say is that there's very weird rendering bug here.

[Ryosuke Niwa]

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.

[Una Sabovic]

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.

[Levi Weintraub]

(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?

[Ryosuke Niwa]

LayoutTests/editing/pasteboard/paste-text-006.html was fixed by the patch for the bug 69377.

[Ryosuke Niwa]

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.

[Ryosuke Niwa]

(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)

[Ryosuke Niwa]

Created attachment 109994 [details]
fixes the test

[Ryosuke Niwa]

Created attachment 110001 [details]
revert WebCore change

[Enrica Casucci]

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.

[Ryosuke Niwa]

Comment on attachment 110001 [details]
revert WebCore change

Clearing flags on attachment: 110001

Committed r96963: <http://trac.webkit.org/changeset/96963>

[Ryosuke Niwa]

All reviewed patches have been landed.  Closing bug.