W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2010

[whatwg] SearchBox API

From: Tony Gentilcore <tonyg@chromium.org>
Date: Thu, 14 Oct 2010 09:51:53 -0700
Message-ID: <AANLkTi=N4NgOQjqaSB+gk3WMUeurspm65kY691K9bncW@mail.gmail.com>
On Thu, Oct 14, 2010 at 8:43 AM, Jonas Sicking <jonas at sicking.cc> wrote:
> On Wed, Oct 13, 2010 at 3:59 PM, Tony Gentilcore <tonyg at chromium.org> wrote:
>> Hi All,
>>
>> We're adding instant search integration [1] to Google Chrome, allowing
>> the search provider to communicate suggestions to the user agent.
>>
>> If there is interest, we'd like to make sure that we do this in such a
>> way that any search provider or user agent can implement it.
>>
>> While the search boxes in most user agents support suggestions via an
>> HTTP API, instant requires a DOM API. We propose exposing a
>> window.navigator.searchBox object.?There is some?precedence?for this
>> with window.navigator.registerProtocolHandler()/registerContentHandler()
>> [2].
>>
>> Is this something that others are interested in? If so, any feedback
>> on our working API [3]?
>>
>> -Tony
>>
>> [1] http://googlesystem.blogspot.com/2010/09/instant-search-in-google-chrome.html
>> [2] http://dev.w3.org/html5/spec/Overview.html#navigator
>> [3]
>>
>> interface SearchBox {
>> ?// Search query and cursor position.
>> ?readonly attribute DOMString value;
>> ?readonly attribute unsigned long selectionStart;
>> ?readonly attribute unsigned long selectionEnd;
>
> I'm not quite sure I understand this proposal. Does this mean that if
> the user has navigated to "http://evil.com/index.html" and starts
> typing in a browser UI search box, outside the website, that the page
> on evil.com can see what the user is typing?

No. Users expect that when they search in the browser's search box, it
searches using their default search provider (or the search provider
they've selected in the box).

The way we've implemented this, if the user is on
http://evil.com/index.html, and they begin typing in the omnibox, it
will provisionally load their default search provider and begin using
the API on the search provider. If they commit a search, it will stay
on the search page, but if they cancel, it will go back to evil.com.
All the while evil.com has no knowledge of this interaction.

This is a bit hard to explain, but feels natural when you use it. If
you have a Windows Chrome Dev channel build, you can enable it in
about:labs to start playing with it. Otherwise, there is a video of an
older version here:
http://www.youtube.com/watch?v=tefRwthQaes

BTW - The old version in the video demonstrates why we need the size
of the overlapping region. The first search result is usually obscured
by the dropdown. In the current version, the search page adapts to the
overlapping region reported by the browser.

>
> Also, this is a pretty big feature. I assume you'll 'chrome' or
> 'webkit' prefix the API for now?

Yes. We wanted to get the conversation started asap so that if there
are major issues that need to be addressed to support additional
search providers and user agents, we'd start to flush them out before
we get too far along with our straw man design. But for now, this
would live somewhere like window.chrome.searchBox,
window.navigator.chromeSearchBox, window.navigator.webkitSearchBox.

>
> / Jonas
>
Received on Thursday, 14 October 2010 09:51:53 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:01 UTC