<br><br><div class="gmail_quote">On Fri, Oct 26, 2012 at 5:01 PM, Lindsay Mathieson <span dir="ltr">&lt;<a href="mailto:lindsay.mathieson@gmail.com" target="_blank">lindsay.mathieson@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">On Fri, 26 Oct 2012 11:54:23 AM Dawit A wrote:<br>
&gt; I guess I was expecting an API that would have allowed me to simply provide<br>
&gt; a list of completion items leaving the means by which those items are shown<br>
&gt; to the user up to QtWebKit. However, I see why that would not be a wise<br>
&gt; choice. I guess a client application can listen to the<br>
&gt; QWebPage::contentsChanged signal and create a popup menu with the<br>
&gt; completion items by relying on these newly added classes.<br>
<br>
</div>I think I was lacking a full understanding of what you were using it for<br>
Dawit. Are you currently creating the autofill alternative choice drop downs<br>
in input fields?<br></blockquote><div><br></div><div>Not really. The API is perfect fine for solving the current issues we have with filling out forms on web pages. What I was implying was, I wanted the API to go even further and offer the ability to provide a list of potential completion items in a popup menu when the user fills out non-login related forms. That was what I was suggesting above. However, I realized that doing such things is probably outside the scope of the browser engine especially since it is something that could be accomplished on the client side.</div>

<div><br></div><div>Regards,</div><div>Dawit A.</div></div>