Bug 176562 - Clean up Geolocation request handling
Summary: Clean up Geolocation request handling
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Alex Christensen
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2017-09-07 13:42 PDT by Alex Christensen
Modified: 2017-09-27 12:43 PDT (History)
8 users (show)

See Also:


Attachments
Patch (21.86 KB, patch)
2017-09-07 13:44 PDT, Alex Christensen
no flags Details | Formatted Diff | Diff
Patch (23.30 KB, patch)
2017-09-07 14:14 PDT, Alex Christensen
no flags Details | Formatted Diff | Diff
Patch (23.30 KB, patch)
2017-09-07 14:19 PDT, Alex Christensen
no flags Details | Formatted Diff | Diff
Patch (25.18 KB, patch)
2017-09-07 14:25 PDT, Alex Christensen
no flags Details | Formatted Diff | Diff
Patch (26.22 KB, patch)
2017-09-07 14:50 PDT, Alex Christensen
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Christensen 2017-09-07 13:42:54 PDT
Clean up Geolocation request handling
Comment 1 Alex Christensen 2017-09-07 13:44:52 PDT
Created attachment 320170 [details]
Patch
Comment 2 Alex Christensen 2017-09-07 14:14:34 PDT
Created attachment 320178 [details]
Patch
Comment 3 Build Bot 2017-09-07 14:15:49 PDT
Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See http://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API
Comment 4 Alex Christensen 2017-09-07 14:19:19 PDT
Created attachment 320179 [details]
Patch
Comment 5 Alex Christensen 2017-09-07 14:25:55 PDT
Created attachment 320181 [details]
Patch
Comment 6 Tim Horton 2017-09-07 14:39:38 PDT
Comment on attachment 320181 [details]
Patch

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

> Source/WebKit/UIProcess/WebPageProxy.cpp:5827
> +    completionHandler = m_uiClient->decidePolicyForGeolocationPermissionRequest(*this, *frame, origin.get(), WTFMove(completionHandler));
> +#if PLATFORM(IOS)
> +    if (completionHandler)
> +        completionHandler = m_pageClient.decidePolicyForGeolocationPermissionRequest(*frame, origin.get(), WTFMove(completionHandler));
> +#endif
> +    if (completionHandler)
> +        completionHandler(false);

This looks SO weird, but you explained it. Maybe a comment?
Comment 7 Alex Christensen 2017-09-07 14:50:15 PDT
Created attachment 320186 [details]
Patch
Comment 8 Alex Christensen 2017-09-07 15:20:54 PDT
http://trac.webkit.org/r221764
Comment 9 Darin Adler 2017-09-10 14:35:20 PDT
Comment on attachment 320186 [details]
Patch

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

> Source/WebKit/ChangeLog:10
> +        Instead of passing a GeolocationPermissionRequestProxy& to each client and returning a bool if the request will be handled,
> +        pass a Function<void(bool)>&& completionHandler and return the function if it won't be handled.
> +        This allows to temporarily support our UIClient/PageClient hybrid design while moving towards a sane design.

Why "return the function if it won’t be handled”?

Seems like we could just have it "not null out the function if it won’t be handled" or "not move the function if it won’t be handled", which is the same thing. The return value seems unneeded.
Comment 10 Darin Adler 2017-09-10 14:36:58 PDT
Comment on attachment 320186 [details]
Patch

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

>> Source/WebKit/ChangeLog:10
>> +        This allows to temporarily support our UIClient/PageClient hybrid design while moving towards a sane design.
> 
> Why "return the function if it won’t be handled”?
> 
> Seems like we could just have it "not null out the function if it won’t be handled" or "not move the function if it won’t be handled", which is the same thing. The return value seems unneeded.

Then I think the argument turns into a:

    Function<void(bool)>&

Because it’s not safe to pass in a new object and then not look at it afterward. Anyway, that’s better than both taking and returning a Function I think.
Comment 11 Radar WebKit Bug Importer 2017-09-27 12:43:14 PDT
<rdar://problem/34693823>