[webkit-reviews] review granted: [Bug 197271] [WPE][GTK] Add WebKitWebPage::did-associate-form-controls-for-frame and deprecate original did-associate-form-controls : [Attachment 369281] Patch

[bugzilla-daemon at webkit.org]

youenn fablet <youennf at gmail.com> has granted Michael Catanzaro
<mcatanzaro at igalia.com>'s request for review:
Bug 197271: [WPE][GTK] Add WebKitWebPage::did-associate-form-controls-for-frame
and deprecate original did-associate-form-controls
https://bugs.webkit.org/show_bug.cgi?id=197271

Attachment 369281: Patch

https://bugs.webkit.org/attachment.cgi?id=369281&action=review




--- Comment #15 from youenn fablet <youennf at gmail.com> ---
Comment on attachment 369281
  --> https://bugs.webkit.org/attachment.cgi?id=369281
Patch

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

> Source/WebKit/WebProcess/InjectedBundle/InjectedBundlePageFormClient.cpp:163
>	   return;

This check should probably be updated so that a client that sets
didAssociateFormControlsForFrame does not have to set didAssociateFormControls.

> Source/WebKit/WebProcess/InjectedBundle/InjectedBundlePageFormClient.cpp:172
> +	   m_client.didAssociateFormControls(toAPI(page),
toAPI(API::Array::create(WTFMove(elementHandles)).ptr()),
m_client.base.clientInfo);

The idea is that the clients should transition from the old one to the new one.
Once a client opt in the new callback, it seems better for the old callback to
become a no-op.