Bug 218050 - [Contact Picker API] Add skeleton implementation of ContactsManager.select()
Summary: [Contact Picker API] Add skeleton implementation of ContactsManager.select()
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: Other
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Aditya Keerthi
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2020-10-21 13:42 PDT by Aditya Keerthi
Modified: 2020-10-22 18:32 PDT (History)
11 users (show)

See Also:


Attachments
Patch (40.73 KB, patch)
2020-10-21 13:47 PDT, Aditya Keerthi
ews-feeder: commit-queue-
Details | Formatted Diff | Diff
Patch (40.92 KB, patch)
2020-10-21 14:17 PDT, Aditya Keerthi
no flags Details | Formatted Diff | Diff
Patch (38.32 KB, patch)
2020-10-22 11:06 PDT, Aditya Keerthi
no flags Details | Formatted Diff | Diff
Patch (38.92 KB, patch)
2020-10-22 14:29 PDT, Aditya Keerthi
ews-feeder: commit-queue-
Details | Formatted Diff | Diff
Patch (38.96 KB, patch)
2020-10-22 14:39 PDT, Aditya Keerthi
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Aditya Keerthi 2020-10-21 13:42:05 PDT
...
Comment 1 Aditya Keerthi 2020-10-21 13:42:29 PDT
<rdar://problem/69862186>
Comment 2 Aditya Keerthi 2020-10-21 13:47:25 PDT
Created attachment 412026 [details]
Patch
Comment 3 Aditya Keerthi 2020-10-21 14:17:15 PDT
Created attachment 412031 [details]
Patch
Comment 4 Aditya Keerthi 2020-10-22 11:06:21 PDT
Created attachment 412116 [details]
Patch
Comment 5 Devin Rousso 2020-10-22 13:48:17 PDT
Comment on attachment 412116 [details]
Patch

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

r=me, assuming you fix the build issues for GTK/WPE/Win/etc :)

> Source/WebCore/Modules/contact-picker/ContactsManager.cpp:82
> +    auto frame = makeRefPtr(this->frame());

Do we actually need to `makeRefPtr` here?  You properly null-check it and don't give it to the lambda, so is it necessary to increase the ref count?

> Source/WebCore/Modules/contact-picker/ContactsManager.cpp:84
> +        promise->reject(Exception { InvalidStateError });

NIT: do we actually need the `Exception { ... }` instead of just `InvalidStateError`?

> Source/WebCore/Modules/contact-picker/ContactsManager.cpp:89
> +        promise->reject(Exception { SecurityError });

ditto (:84)

> Source/WebCore/Modules/contact-picker/ContactsManager.cpp:94
> +        promise->reject(Exception { InvalidStateError });

ditto (:84)

> Source/WebCore/Modules/contact-picker/ContactsManager.cpp:113
> +        if (info) {

Is it actually necessary to wrap the `Vector` in an `Optional`?  Can we just have the `Vector` be the response, which resolves the `promise` with an empty array in that case?  Or do we explicitly want/need to differentiate between "the user did not pick any contacts" and "WebKit was unable to show the picker UI"?

> Source/WebCore/Modules/contact-picker/ContactsManager.cpp:118
> +        promise->reject(Exception { UnknownError });

ditto (:84)

> Source/WebCore/Modules/contact-picker/ContactsManager.h:58
> +    bool m_contactPickerIsShowing { false };

I'd put this below for (potentially) better packing

> Source/WebKit/UIProcess/PageClient.h:258
> +    virtual void showContactPicker(const WebCore::ContactsRequestData&, WTF::CompletionHandler<void(Optional<Vector<WebCore::ContactInfo>>&&)>&& completionHandler) { completionHandler(WTF::nullopt); }

So this patch doesn't hook this up to `PageClientImplCocoa`/`PageClientImplMac`/`PageClientImplIOS`/?  If so, could we maybe retitle this bug so it's clear that we're only implementing the skeleton/structure of this functionality (and add a related/blocked bug for the rest of it)?
Comment 6 Aditya Keerthi 2020-10-22 14:29:04 PDT
Created attachment 412132 [details]
Patch
Comment 7 Aditya Keerthi 2020-10-22 14:34:21 PDT
(In reply to Devin Rousso from comment #5)
> Comment on attachment 412116 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=412116&action=review
> 
> r=me, assuming you fix the build issues for GTK/WPE/Win/etc :)

Thank you for the review :)

> > Source/WebCore/Modules/contact-picker/ContactsManager.cpp:82
> > +    auto frame = makeRefPtr(this->frame());
> 
> Do we actually need to `makeRefPtr` here?  You properly null-check it and
> don't give it to the lambda, so is it necessary to increase the ref count?

Removed `makeRefPtr`.

> > Source/WebCore/Modules/contact-picker/ContactsManager.cpp:84
> > +        promise->reject(Exception { InvalidStateError });
> 
> NIT: do we actually need the `Exception { ... }` instead of just
> `InvalidStateError`?

No need for the `Exception { ... }`. Corrected this instance and the others below.

> > Source/WebCore/Modules/contact-picker/ContactsManager.cpp:113
> > +        if (info) {
> 
> Is it actually necessary to wrap the `Vector` in an `Optional`?  Can we just
> have the `Vector` be the response, which resolves the `promise` with an
> empty array in that case?  Or do we explicitly want/need to differentiate
> between "the user did not pick any contacts" and "WebKit was unable to show
> the picker UI"?

We need to differentiate between the two.

The spec states "If presenting a user interface fails or accessing the contacts source's available contacts fails, then return failure." This is distinct from the empty list case: "The UI MUST provide an option to cancel/return without sharing any contacts, in which case remove the UI and return an empty list."
 
> > Source/WebCore/Modules/contact-picker/ContactsManager.h:58
> > +    bool m_contactPickerIsShowing { false };
> 
> I'd put this below for (potentially) better packing

Done.

> > Source/WebKit/UIProcess/PageClient.h:258
> > +    virtual void showContactPicker(const WebCore::ContactsRequestData&, WTF::CompletionHandler<void(Optional<Vector<WebCore::ContactInfo>>&&)>&& completionHandler) { completionHandler(WTF::nullopt); }
> 
> So this patch doesn't hook this up to
> `PageClientImplCocoa`/`PageClientImplMac`/`PageClientImplIOS`/?  If so,
> could we maybe retitle this bug so it's clear that we're only implementing
> the skeleton/structure of this functionality (and add a related/blocked bug
> for the rest of it)?

Correct. I've renamed the bug.
Comment 8 Aditya Keerthi 2020-10-22 14:39:34 PDT
Created attachment 412134 [details]
Patch
Comment 9 Aditya Keerthi 2020-10-22 14:40:03 PDT
Added a missing header to Headers.cmake.
Comment 10 EWS 2020-10-22 18:32:14 PDT
Committed r268901: <https://trac.webkit.org/changeset/268901>

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