[autofill] Adding new API to request an interactive autocomplete UI flow.

content/renderer/render_view_impl.h

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef CONTENT_RENDERER_RENDER_VIEW_IMPL_H_
 #define CONTENT_RENDERER_RENDER_VIEW_IMPL_H_
 
 #include <set>
 
 #include "base/basictypes.h"
@@ skipping 86 matching lines @@
 }
 #endif
 
 namespace WebKit {
 class WebApplicationCacheHost;
 class WebApplicationCacheHostClient;
 class WebCompositorOutputSurface;
 class WebDOMMessageEvent;
 class WebDataSource;
 class WebDragData;
+class WebFormElement;
 class WebGeolocationClient;
 class WebGestureEvent;
 class WebIconURL;
 class WebImage;
 class WebPeerConnection00Handler;
 class WebPeerConnection00HandlerClient;
 class WebMediaPlayer;
 class WebMediaPlayerClient;
 class WebMouseEvent;
 class WebPeerConnectionHandler;
@@ skipping 330 matching lines @@
                                      double load_progress);
   virtual bool isSmartInsertDeleteEnabled();
   virtual bool isSelectTrailingWhitespaceEnabled();
   virtual void didChangeSelection(bool is_selection_empty);
   virtual void didExecuteCommand(const WebKit::WebString& command_name);
   virtual bool handleCurrentKeyboardEvent();
   virtual void didHandleGestureEvent(const WebKit::WebGestureEvent& event,
                                      bool event_swallowed) OVERRIDE;
   virtual WebKit::WebColorChooser* createColorChooser(
       WebKit::WebColorChooserClient*, const WebKit::WebColor& initial_color);
+  virtual void requestAutocomplete(WebKit::WebFrame* frame,

[jam, 2012/10/26 20:09:38]

which interface is this from (I couldn't find it on trac)?

autofill related methods should be on WebAutofillClient. that's why that
interface got added, so that autofill callbacks from webkit go straight to
chrome instead of hopping through content

[Dan Beam, 2012/10/26 20:58:39]

sorry, the WebKit stuff isn't in yet, it's in review -
https://bugs.webkit.org/show_bug.cgi?id=100557
the only thing that implements this interface right now is
AutofillPopupMenuClient.  This isn't really related to popup menus.  I asked
isherman@ if he'd like me to make AutofillPopupMenuClient more generic (i.e.
AutofillClient or something like that) so I could include this method there, but
he said that AutofillPopupMenuClient is deprecated as it's in the process of
being moved.  isherman@, is this correct?

[jam, 2012/10/26 21:06:04]

you need to look in the chromium repo (not webkit), see
http://code.google.com/searchframe#OAMlx_jo-ck/src/chrome/renderer/autofill/a...

AutofillAgent (which you're modifying to get the call through
RenderViewObserver) implements WebAutofillClient.

[Ilya Sherman, 2012/10/26 23:18:42]

John, the WebAutofillClient class is currently primarily responsible for
implementing a UI that lives in the renderer.  Chris Sharp is currently working
on moving that UI into the browser process.  Once that work is complete, the
WebAutofillClient will only have three methods:

virtual void textFieldDidEndEditing(const WebInputElement&)
virtual void textFieldDidChange(const WebInputElement&)
virtual void textFieldDidReceiveKeyDown(const WebInputElement&, const
WebKeyboardEvent&)

(plus possibly this new one).  These methods are really not any more
Autofill-specific than is e.g. WillSubmitForm() from the RenderViewObserver
class (unless I'm just unaware of other clients of that method).  Given that the
WebAutofillClient class is shrinking to just handling these events, is it still
appropriate to add this new method to that class, rather than simply removing
the class once the UI migration work is finished?  Put another way: When should
methods be added to the RenderViewObserver, rather than routed via a more
specific WebFooClient class?  Should WillSubmitForm() be moved into this class
as well?

[jam, 2012/10/26 23:48:47]

When I created WebAutofillClient, and the other related interfaces (spellcheck,
devtools), the criteria was that each interface would get a set of related
callbacks from WebKit that were currently on WebViewClient/WebFrameClient. These
callbacks were only used by one feature. So in the example above, willSubmitForm
needs to stay in content because RenderViewImpl does do stuff in that callback.

So yes, I think the function should move, and stay with the methods that are
remaining in that interface.

[Ilya Sherman, 2012/10/27 00:33:36]

Ok, I didn't realize that was the history for this interface -- this makes more
sense now.  Thanks for explaining!

+                                   const WebKit::WebFormElement& form);
   virtual bool runFileChooser(
       const WebKit::WebFileChooserParams& params,
       WebKit::WebFileChooserCompletion* chooser_completion);
   virtual void runModalAlertDialog(WebKit::WebFrame* frame,
                                    const WebKit::WebString& message);
   virtual bool runModalConfirmDialog(WebKit::WebFrame* frame,
                                      const WebKit::WebString& message);
   virtual bool runModalPromptDialog(WebKit::WebFrame* frame,
                                     const WebKit::WebString& message,
                                     const WebKit::WebString& default_value,
@@ skipping 1122 matching lines @@
   // use the Observer interface to filter IPC messages and receive frame change
   // notifications.
   // ---------------------------------------------------------------------------
 
   DISALLOW_COPY_AND_ASSIGN(RenderViewImpl);
 };
 
 }  // namespace content
 
 #endif  // CONTENT_RENDERER_RENDER_VIEW_IMPL_H_