Bug 153813 – Accepted candidates should not be autocorrected

• Status: RESOLVED
• Resolution: FIXED
• Component: HTML Editing

[Beth Dakin]

Accepted candidates can be autocorrected. That should not happen.

rdar://problem/24066924

[Beth Dakin]

Created attachment 270540 [details]
Patch

[Darin Adler]

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.

[Tim Horton]

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

[Beth Dakin]

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

[Beth Dakin]

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.

[Beth Dakin]

I forgot to commit the test!! http://trac.webkit.org/changeset/196105