Accepted candidates can be autocorrected. That should not happen. rdar://problem/24066924
Created attachment 270540 [details] Patch
Comment on attachment 270540 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=270540&action=review Can we make a regression test for this? > Source/WebCore/editing/Editor.cpp:3575 > + RefPtr<Range> insertedCandidateRange = rangeExpandedAroundPositionByCharacters(selection.visibleStart(), candidateLength); If we are guaranteed this can’t be null, I’m surprised it’s a RefPtr, not a Ref. If not, then the next line could result in a crash, and so we should add a null check.
(In reply to comment #2) > Comment on attachment 270540 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=270540&action=review > > Can we make a regression test for this? > > > Source/WebCore/editing/Editor.cpp:3575 > > + RefPtr<Range> insertedCandidateRange = rangeExpandedAroundPositionByCharacters(selection.visibleStart(), candidateLength); > > If we are guaranteed this can’t be null, I’m surprised it’s a RefPtr, not a > Ref. If not, then the next line could result in a crash, and so we should > add a null check. Pretty sure it's the latter.
(In reply to comment #2) > Comment on attachment 270540 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=270540&action=review > > Can we make a regression test for this? > I've been working at it today. I thought it would be possible, and it is in the sense that I can easily add something to Internals to exercise this code path. However, I am having a lot of trouble making a test that fails without my fix. After a lot of fiddling, I am starting to believe that the only way to tigger autocorrection in the layout tests is to insert the characters one at a time. So in the context of the test harness, inserting a candidate all at once never triggered the bug. I think this is the case, but I am still trying to confirm. > > Source/WebCore/editing/Editor.cpp:3575 > > + RefPtr<Range> insertedCandidateRange = rangeExpandedAroundPositionByCharacters(selection.visibleStart(), candidateLength); > > If we are guaranteed this can’t be null, I’m surprised it’s a RefPtr, not a > Ref. If not, then the next line could result in a crash, and so we should > add a null check. Indeed, I think a null check is in order. I seem to have a mental block regarding null-checking ranges.
http://trac.webkit.org/changeset/196090 After sorting through some major confusion, I finally made a test! None of the spelling-correction tests work at all in WK2, and that was the root of much confusion. But I was able to write a test for WK1 that does indeed fail without the fix.
I forgot to commit the test!! http://trac.webkit.org/changeset/196105