Bug 235830

Summary: Add SPI to retrieve the rect of a found text range
Product: WebKit Reporter: Aditya Keerthi <akeerthi>
Component: WebKit APIAssignee: Aditya Keerthi <akeerthi>
Status: RESOLVED FIXED    
Severity: Normal CC: darin, hi, megan_gardner, thorton, webkit-bug-importer, wenson_hsieh
Priority: P2 Keywords: InRadar
Version: Other   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 235692, 235693    
Bug Blocks:    
Attachments:
Description Flags
Patch
none
Patch
none
Patch
wenson_hsieh: review+
Patch for landing none

Description Aditya Keerthi 2022-01-28 10:34:35 PST
...
Comment 1 Aditya Keerthi 2022-01-28 10:34:50 PST
rdar://88193004
Comment 2 Aditya Keerthi 2022-01-28 10:42:16 PST
Created attachment 450255 [details]
Patch
Comment 3 Aditya Keerthi 2022-01-28 11:59:39 PST
Created attachment 450264 [details]
Patch
Comment 4 Darin Adler 2022-01-28 12:09:58 PST
Comment on attachment 450264 [details]
Patch

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

> Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:10145
> +    WKFoundTextRange *foundTextRange = (WKFoundTextRange *)range;

Local variable doesn’t add much value and involves repeating WKFoundTextRange twice, which we could mitigate with auto. Also, could use dynamic_objc_cast or checked_objc_cast if you like; they are for this.

> Source/WebKit/WebProcess/WebPage/WebFoundTextRangeController.cpp:184
> +    auto rect = frameView->contentsToRootView(WebCore::unionRect(WebCore::RenderObject::absoluteTextRects(*simpleRange)));

local variable doesn’t help here

We may not need the WebCore prefix on the call unionRect because of argument-dependent lookup, since the type is in the WebCore namespace.

> Tools/TestWebKitAPI/Tests/WebKitCocoa/FindInPage.mm:410
> +    auto searchOptions = adoptNS([[TestTextSearchOptions alloc] init]);

Would just name this local "options".

> Tools/TestWebKitAPI/Tests/WebKitCocoa/FindInPage.mm:411
> +    [webView performTextSearchWithQueryString:query usingOptions:(_UITextSearchOptions *)searchOptions.get() resultAggregator:aggregator.get()];

Why is a typecast to _UITextSearchOptions needed here? That does not seem right!

> Tools/TestWebKitAPI/Tests/WebKitCocoa/FindInPage.mm:500
> +    RetainPtr<NSArray<UITextRange *>> ranges = adoptNS(getTextRangesForQueryString(webView.get(), @"Sapien"));

I suggest auto here.
Comment 5 Aditya Keerthi 2022-01-28 13:21:11 PST
Created attachment 450273 [details]
Patch
Comment 6 Aditya Keerthi 2022-01-28 13:23:25 PST
(In reply to Darin Adler from comment #4)
> Comment on attachment 450264 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=450264&action=review
> 
> > Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:10145
> > +    WKFoundTextRange *foundTextRange = (WKFoundTextRange *)range;
> 
> Local variable doesn’t add much value and involves repeating
> WKFoundTextRange twice, which we could mitigate with auto. Also, could use
> dynamic_objc_cast or checked_objc_cast if you like; they are for this.

Did not know about `dynamic_objc_cast`! Decided to go with that.
 
> > Source/WebKit/WebProcess/WebPage/WebFoundTextRangeController.cpp:184
> > +    auto rect = frameView->contentsToRootView(WebCore::unionRect(WebCore::RenderObject::absoluteTextRects(*simpleRange)));
> 
> local variable doesn’t help here
> 
> We may not need the WebCore prefix on the call unionRect because of
> argument-dependent lookup, since the type is in the WebCore namespace.

Removed local variable and prefix.
 
> > Tools/TestWebKitAPI/Tests/WebKitCocoa/FindInPage.mm:410
> > +    auto searchOptions = adoptNS([[TestTextSearchOptions alloc] init]);
> 
> Would just name this local "options".

Done.

> > Tools/TestWebKitAPI/Tests/WebKitCocoa/FindInPage.mm:411
> > +    [webView performTextSearchWithQueryString:query usingOptions:(_UITextSearchOptions *)searchOptions.get() resultAggregator:aggregator.get()];
> 
> Why is a typecast to _UITextSearchOptions needed here? That does not seem
> right!

The typecast is because UIKit doesn't export this symbol yet. I've added a comment and linked to the corresponding bug.
 
> > Tools/TestWebKitAPI/Tests/WebKitCocoa/FindInPage.mm:500
> > +    RetainPtr<NSArray<UITextRange *>> ranges = adoptNS(getTextRangesForQueryString(webView.get(), @"Sapien"));
> 
> I suggest auto here.

Done.
Comment 7 Wenson Hsieh 2022-01-28 15:58:28 PST
Comment on attachment 450273 [details]
Patch

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

> Tools/TestWebKitAPI/Tests/WebKitCocoa/FindInPage.mm:343
> +@property (nonatomic, readonly) NSArray<UITextRange *>* foundRanges;

Nit - the *s are inconsistent here.

> Tools/TestWebKitAPI/Tests/WebKitCocoa/FindInPage.mm:501
> +    auto ranges = adoptNS(getTextRangesForQueryString(webView.get(), @"Sapien"));

Nit - functions that return +1 Objective-C ids usually start with names like "copy" or "new".

Perhaps, `copyTextRangesForQueryString`? (Or you could just move the adoptNS into the helper function itself, and return a RetainPtr instead).
Comment 8 Aditya Keerthi 2022-01-28 16:22:09 PST
Created attachment 450286 [details]
Patch for landing
Comment 9 Aditya Keerthi 2022-01-28 16:23:10 PST
(In reply to Wenson Hsieh from comment #7)
> Comment on attachment 450273 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=450273&action=review
> 
> > Tools/TestWebKitAPI/Tests/WebKitCocoa/FindInPage.mm:343
> > +@property (nonatomic, readonly) NSArray<UITextRange *>* foundRanges;
> 
> Nit - the *s are inconsistent here.

Fixed.
 
> > Tools/TestWebKitAPI/Tests/WebKitCocoa/FindInPage.mm:501
> > +    auto ranges = adoptNS(getTextRangesForQueryString(webView.get(), @"Sapien"));
> 
> Nit - functions that return +1 Objective-C ids usually start with names like
> "copy" or "new".
> 
> Perhaps, `copyTextRangesForQueryString`? (Or you could just move the adoptNS
> into the helper function itself, and return a RetainPtr instead).

Moved the adoptNS into the helper function.
Comment 10 EWS 2022-01-28 17:25:06 PST
Committed r288773 (246554@main): <https://commits.webkit.org/246554@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 450286 [details].