WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
69060
REGRESSION(
r96257
): fast/repaint/selection-clear.html fail
https://bugs.webkit.org/show_bug.cgi?id=69060
Summary
REGRESSION(r96257): fast/repaint/selection-clear.html fail
Ryosuke Niwa
Reported
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.
Attachments
fixes the test
(18.01 KB, patch)
2011-10-06 12:26 PDT
,
Ryosuke Niwa
no flags
Details
Formatted Diff
Diff
revert WebCore change
(16.83 KB, patch)
2011-10-06 13:09 PDT
,
Ryosuke Niwa
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Ryosuke Niwa
Comment 1
2011-09-28 23:01:49 PDT
http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=fast%2Frepaint%2Fselection-clear.html%2Cediting%2Fpasteboard%2Fpaste-text-006.html
Ryosuke Niwa
Comment 2
2011-09-28 23:05:05 PDT
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
Comment 3
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.
Ryosuke Niwa
Comment 4
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.
Una Sabovic
Comment 5
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.
Levi Weintraub
Comment 6
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?
Ryosuke Niwa
Comment 7
2011-10-06 12:03:35 PDT
LayoutTests/editing/pasteboard/paste-text-006.html was fixed by the patch for the
bug 69377
.
Ryosuke Niwa
Comment 8
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.
Ryosuke Niwa
Comment 9
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)
Ryosuke Niwa
Comment 10
2011-10-06 12:26:00 PDT
Created
attachment 109994
[details]
fixes the test
Ryosuke Niwa
Comment 11
2011-10-06 13:09:48 PDT
Created
attachment 110001
[details]
revert WebCore change
Enrica Casucci
Comment 12
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.
Ryosuke Niwa
Comment 13
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
>
Ryosuke Niwa
Comment 14
2011-10-07 11:46:57 PDT
All reviewed patches have been landed. Closing bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug