WKPageFindStringMatches ignores the kWKFindOptionsBackwards option

[Enrica Casucci]

The API will always return the matched ranges in the DOM order and that is the expected behavior, but it should respect the backwards options when considering the match after the user selection.

<rdar://problem/13881024>

[Enrica Casucci]

Created attachment 204733 [details]
Patch

[Build Bot]

Comment on attachment 204733 [details]
Patch

Attachment 204733 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.appspot.com/results/846302

[Darin Adler]

Comment on attachment 204733 [details]
Patch

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

I think the test coverage might still be a bit light. It would be good to exercise even more edge cases. No specific ideas for that, though.

r=me if you fix the header and thus fix the build

> Source/WebKit2/Shared/API/c/WKFindOptions.h:45
> +const int kWKFindResultNoMatchAfterUserSelection = -1;

Since this is a C header we can’t use:

    const int kWKFindResultNoMatchAfterUserSelection = -1;

We can follow the CoreFoundation style and use an enum for this:

    enum { kWKFindResultNoMatchAfterUserSelection = -1 };

Or we can perhaps use this:

    static const int kWKFindResultNoMatchAfterUserSelection = -1;

This is why the Mac build is failing.

[Enrica Casucci]

Fixed header file to use enum.

Committed revision 151607.