Bug 137902

Summary: REGRESSION (r165385): Crash when applying autocorrection exceeds maximum text area length.
Product: WebKit Reporter: Gavin Sherlock <gsherloc>
Component: TextAssignee: Enrica Casucci <enrica>
Status: RESOLVED FIXED    
Severity: Critical CC: bfulgham, commit-queue, darin, enrica, simon.fraser
Priority: P1 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: Mac   
OS: OS X 10.9   
URL: http://www.apple.com/feedback/
Attachments:
Description Flags
crash log
none
Patch
darin: review-
New patch darin: review+

Description Gavin Sherlock 2014-10-20 17:26:50 PDT
Created attachment 240162 [details]
crash log

Note - this is Safari 8, on OS X 10.10, but I can't actually select those from the drop downs.

Steps to reproduce:

1.  Go to Apple's feedback page
2.  Write a rant about how you hate the new behavior of the zoom buttons on Finder windows, where the last word is intended to be "awful", but only "awfu" fits.
3.  When Safari suggests "awful" as the completion, select it

Expected results:

Either "awful" is added, or it leaves it as "awfu"

Actual results:

Boom - tab crashes, losing you everything you just typed in. :-/


Crash report attached
Comment 1 Alexey Proskuryakov 2014-10-20 23:10:05 PDT
Tracked internally as rdar://problem/18568864 and related bugs.
Comment 2 Enrica Casucci 2014-12-17 15:54:03 PST
Created attachment 243466 [details]
Patch
Comment 3 Darin Adler 2014-12-17 17:55:19 PST
Comment on attachment 243466 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=243466&action=review

> Source/WebCore/editing/TextIterator.cpp:1098
> -    ASSERT(!atEnd());
> +    if (atEnd())
> +        return nullptr;

It’s the caller’s responsibility to check atEnd(). This is a design change. I don’t think we should change the design of TextIterator. Instead we should fix the caller that is not checking atEnd(). In fact, I think this function should return Ref<Range> and not PassRefPtr<Range> in the future.

> Source/WebCore/editing/TextIterator.cpp:1389
> -    ASSERT(!atEnd());
> +    if (atEnd())
> +        return nullptr;

Ditto.

> Source/WebCore/editing/TextIterator.cpp:1473
> +    if (!start)
> +        return nullptr;

This should be if (it.atEnd()) return nullptr; *before* calling it.range().

> Source/WebCore/editing/TextIterator.cpp:1479
> +    if (!end)
> +        return nullptr;

Ditto.
Comment 4 Darin Adler 2014-12-17 17:57:08 PST
Comment on attachment 243466 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=243466&action=review

>> Source/WebCore/editing/TextIterator.cpp:1473
>> +        return nullptr;
> 
> This should be if (it.atEnd()) return nullptr; *before* calling it.range().

I think we might also need to check if (it.atEnd()) before calling it.advance()?
Comment 5 Darin Adler 2014-12-17 18:03:42 PST
Comment on attachment 243466 [details]
Patch

I’d also like to see a regression test. Any reason we can’t make one?
Comment 6 Enrica Casucci 2014-12-17 18:19:04 PST
(In reply to comment #3)
> Comment on attachment 243466 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=243466&action=review
> 
> > Source/WebCore/editing/TextIterator.cpp:1098
> > -    ASSERT(!atEnd());
> > +    if (atEnd())
> > +        return nullptr;
> 
> It’s the caller’s responsibility to check atEnd(). This is a design change.
> I don’t think we should change the design of TextIterator. Instead we should
> fix the caller that is not checking atEnd(). In fact, I think this function
> should return Ref<Range> and not PassRefPtr<Range> in the future.

Ok, I understand now. I'll change it.
> 
> > Source/WebCore/editing/TextIterator.cpp:1389
> > -    ASSERT(!atEnd());
> > +    if (atEnd())
> > +        return nullptr;
> 
> Ditto.
> 
> > Source/WebCore/editing/TextIterator.cpp:1473
> > +    if (!start)
> > +        return nullptr;
> 
> This should be if (it.atEnd()) return nullptr; *before* calling it.range().
> 
> > Source/WebCore/editing/TextIterator.cpp:1479
> > +    if (!end)
> > +        return nullptr;
> 
> Ditto.
Comment 7 Enrica Casucci 2014-12-17 18:20:00 PST
(In reply to comment #5)
> Comment on attachment 243466 [details]
> Patch
> 
> I’d also like to see a regression test. Any reason we can’t make one?

I think it is possible, testing the autocorrection case at the end of the field.
Comment 8 Enrica Casucci 2015-01-12 15:59:26 PST
Created attachment 244475 [details]
New patch
Comment 9 WebKit Commit Bot 2015-01-12 16:02:38 PST
Attachment 244475 [details] did not pass style-queue:


ERROR: Source/WebCore/testing/Internals.h:161:  The parameter name "range" adds no information, so it should be removed.  [readability/parameter_name] [5]
Total errors found: 1 in 8 files


If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 10 Darin Adler 2015-01-13 20:54:08 PST
Comment on attachment 244475 [details]
New patch

View in context: https://bugs.webkit.org/attachment.cgi?id=244475&action=review

> Source/WebCore/editing/TextIterator.cpp:2391
> +    return characterSubrange(entireRange->startContainer()->document(), entireRangeIterator, characterOffset, characterCount);

What guarantees startContainer is non-null? If callers passed a detached range, then that might be null. I suggest using entireRange->ownerDocument() instead.

> Source/WebCore/editing/TextIterator.cpp:2611
> +    return characterSubrange(range.startContainer()->document(), computeRangeIterator, matchStart, matchLength);

Ditto.
Comment 11 Enrica Casucci 2015-01-14 10:21:49 PST
(In reply to comment #10)
> What guarantees startContainer is non-null? If callers passed a detached
> range, then that might be null. I suggest using entireRange->ownerDocument()
> instead.

That is a valid point. I'll change it before landing the patch. Thanks for the review.
Comment 12 Enrica Casucci 2015-01-14 16:19:14 PST
Committed revision 178462.
Comment 13 Brent Fulgham 2015-01-14 17:14:31 PST
This broke the Windows build, because it started using 'TextIterator::subrange', which is not exported by WebKitExports.def.

I'll land a fix shortly.
Comment 14 Brent Fulgham 2015-01-14 18:15:36 PST
Windows build fix committed in r178470.