Bug 69060

Summary: REGRESSION(r96257): fast/repaint/selection-clear.html fail
Product: WebKit Reporter: Ryosuke Niwa <rniwa>
Component: Layout and RenderingAssignee: Ryosuke Niwa <rniwa>
Status: RESOLVED FIXED    
Severity: Normal CC: darin, enrica, hyatt, leviw, mitz, mjs, una.sabovic
Priority: P1    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 69377    
Bug Blocks:    
Attachments:
Description Flags
fixes the test
none
revert WebCore change none

Description Ryosuke Niwa 2011-09-28 22:51:17 PDT
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.
Comment 3 Ryosuke Niwa 2011-09-29 00:24:48 PDT
I've spent some time investigating this issue but all I can say is that there's very weird rendering bug here.
Comment 4 Ryosuke Niwa 2011-09-29 00:26:19 PDT
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.
Comment 5 Una Sabovic 2011-09-29 11:46:35 PDT
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.
Comment 6 Levi Weintraub 2011-09-29 11:48:51 PDT
(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?
Comment 7 Ryosuke Niwa 2011-10-06 12:03:35 PDT
LayoutTests/editing/pasteboard/paste-text-006.html was fixed by the patch for the bug 69377.
Comment 8 Ryosuke Niwa 2011-10-06 12:20:54 PDT
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.
Comment 9 Ryosuke Niwa 2011-10-06 12:21:32 PDT
(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)
Comment 10 Ryosuke Niwa 2011-10-06 12:26:00 PDT
Created attachment 109994 [details]
fixes the test
Comment 11 Ryosuke Niwa 2011-10-06 13:09:48 PDT
Created attachment 110001 [details]
revert WebCore change
Comment 12 Enrica Casucci 2011-10-06 16:08:57 PDT
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 13 Ryosuke Niwa 2011-10-07 11:46:52 PDT
Comment on attachment 110001 [details]
revert WebCore change

Clearing flags on attachment: 110001

Committed r96963: <http://trac.webkit.org/changeset/96963>
Comment 14 Ryosuke Niwa 2011-10-07 11:46:57 PDT
All reviewed patches have been landed.  Closing bug.