Bug 134808 – Phone numbers that span two lines are not detected

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit2

[Brady Eidson]

Phone numbers that span two lines are not detected.

<rdar://problem/17601146>

[Brady Eidson]

Created attachment 234716 [details]
Patch v1

[Tim Horton]

Comment on attachment 234716 [details]
Patch v1 

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

> Source/WebCore/editing/Editor.cpp:3397
> +        // If this text iterator range's end position is before the end of the full range,
> +        // then scan a window that is a bit before and a bit after this text iterator range.

Why do we not search backwards a bit if we end at the end of the range?

[Brady Eidson]

(In reply to comment #2)
> (From update of attachment 234716 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=234716&action=review
> 
> > Source/WebCore/editing/Editor.cpp:3397
> > +        // If this text iterator range's end position is before the end of the full range,
> > +        // then scan a window that is a bit before and a bit after this text iterator range.
> 
> Why do we not search backwards a bit if we end at the end of the range?

Currently when we extend a range to search it, we extend it 15 characters in both directions.

So if we did what you suggest, we would be expanding the end of the end range to 15 previous.

Quite often in practice, the final chunk of text from the iterator will already have been 15 characters long, so doing this extension would be re-scanning those 15 characters.

But if the final chunk was shorter than 15 characters - say it was 1 character - then we already would've scanned that range by extending the end of the previous chunk 15 characters *forward*

Combine this with the fact that the original input range is extended 15 in each direction from the actual selection, and I don't see how stopping at the end would miss anything we want to scan.

[Brady Eidson]

http://trac.webkit.org/changeset/171016