Bug 117647

Summary: WKPageFindStringMatches ignores the kWKFindOptionsBackwards option
Product: WebKit Reporter: Enrica Casucci <enrica>
Component: WebKit2Assignee: Enrica Casucci <enrica>
Status: RESOLVED FIXED    
Severity: Normal CC: buildbot, rniwa
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: All   
OS: Unspecified   
Attachments:
Description Flags
Patch darin: review+, buildbot: commit-queue-

Description Enrica Casucci 2013-06-14 11:55:46 PDT 
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>
Comment 1 Enrica Casucci 2013-06-14 13:31:36 PDT 
Created attachment 204733 [details]
Patch
Comment 2 Build Bot 2013-06-14 14:16:04 PDT 
Comment on attachment 204733 [details]
Patch

Attachment 204733 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.appspot.com/results/846302
Comment 3 Darin Adler 2013-06-14 14:25:45 PDT 
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.
Comment 4 Enrica Casucci 2013-06-14 15:21:58 PDT 
Fixed header file to use enum.

Committed revision 151607.