Bug 153813

Summary: Accepted candidates should not be autocorrected
Product: WebKit Reporter: Beth Dakin <bdakin>
Component: HTML EditingAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: bdakin, enrica, sam, thorton
Priority: P2    
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch darin: review+

Description Beth Dakin 2016-02-02 18:59:40 PST
Accepted candidates can be autocorrected. That should not happen.

rdar://problem/24066924
Comment 1 Beth Dakin 2016-02-02 19:10:29 PST
Created attachment 270540 [details]
Patch
Comment 2 Darin Adler 2016-02-02 20:31:56 PST
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.
Comment 3 Tim Horton 2016-02-02 21:44:40 PST
(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.
Comment 4 Beth Dakin 2016-02-03 14:41:40 PST
(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.
Comment 5 Beth Dakin 2016-02-03 16:04:08 PST
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.
Comment 6 Beth Dakin 2016-02-03 19:36:59 PST
I forgot to commit the test!! http://trac.webkit.org/changeset/196105