Re: [webkit-dev] SearchBox API
On Mar 19, 2011, at 10:10 AM, Adam Barth wrote: Sorry to resurrect this old thread, but what are the DOM APIs in Safari that are accessible only to search providers? Two functions on the window object, getSearchEngine and setSearchEngine. They take and return strings that are the names of supported search engines. The designs are a bit primitive in part because this is an old API that dates back to the first iPhone. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SearchBox API
On Sun, Mar 20, 2011 at 3:26 PM, Darin Adler da...@apple.com wrote: On Mar 19, 2011, at 10:10 AM, Adam Barth wrote: Sorry to resurrect this old thread, but what are the DOM APIs in Safari that are accessible only to search providers? Two functions on the window object, getSearchEngine and setSearchEngine. They take and return strings that are the names of supported search engines. The designs are a bit primitive in part because this is an old API that dates back to the first iPhone. Thanks. It makes sense to me that those functions are implemented by the embedder and not by the engine itself because they're essentially APIs for interacting with the user's preferences. Experimenting with those APIs in the inspector, they have some of the same properties that make me sad about the SearchBox API. For example: window.getSearchEngine.toString() [object CallbackObject] whereas, window.postMessage.toString() function postMessage() { [native code] } In particular, these injected objects don't behave the same way as built-in objects do. That means we're making visible to the web platform the internal organizational structure of the folks who implemented the platform. For getSeachEngine / setSearchEngine, the differences appear superficial. However, the situation with the SearchBox API is worse, in a sense, because the SearchBox API is naturally expressed in terms of DOM events. For example, when the user changes the contents of search field, the SearchBox object receives a change event and when the user submits a search query, the SearchBox object receives a submit event, etc. When implemented by the embedder, the SearchBox API can't really make use of all the event-related machinery in WebCore. As an example, SearchBox isn't an EventTarget, as implemented, and has fake events that don't behave like real events (e.g., window.event doesn't have the proper behavior). Maybe it's not worth fixing, but it bugs me that the API is contorted because of the organizational structure of the project. For example, if Mozilla had implemented a similar API in Firefox, I'm sure it would have just used normal DOM events that behave like all the other events in the platform. To me the cost of exposing a contorted API to the web seems greater than the cost of implementing the API in WebCore behind an ENABLE ifdef. On Sun, Mar 20, 2011 at 2:34 PM, Olli Pettay olli.pet...@helsinki.fi wrote: On 03/20/2011 01:36 AM, Tony Gentilcore wrote: Back in October I proposed the SearchBox API to the whatwg [1]. It enables instant style interaction between the user agent's search box and the default search provider's results page. When I tried instant search on Chrome, it did something only when I was typing an url. It preloaded possibly right url before I pressed enter. It didn't seem to utilize the coordinate information of SearchBox API at all. (Perhaps I wasn't testing it correctly) A browser could certainly preload pages similarly even without the API. The instant search feature has a bunch of different components. One aspect is URL preloading, which happens when the browser thinks you're typing something navigational (like a URL) into the omnibox and is not related to the SearchBox API. Another aspect is what happens when the browser thinks you're tying something search-like (like potato) into the omnibox. In that case, the browser displays a search engine results page. So, why does the search page need any data? The SearchBox API has a two-way flow of information between the search engine results page (SERP) and the browser's search field. (In Chrome's case, that's the omnibox, but it would work just as sensibly for browsers with a dedicated search box.) Essentially, the browser tells the SERP various information about what the user has typed in the search field (much like the web site would learn if the user typed into a text input field in the web site) and the SERP tells the browser some suggested completions for what the user has typed so far (e.g., so the browser can display those suggestions to the user). Additionally, the browser can tell the SERP about the geometry of the search field (if it overlaps the SERP), which lets the SERP move its UI out from underneath the search field, if desired. Couldn't browser interact with the web search in the background and show (and possibly preload) results the way it wants to. That way there wouldn't be an API which fits in to only one kind of UI. I wasn't involved in the design, but I suspect there are latency and synchronization challenges with that approach. Most modern browsers use that approach for showing search suggestions in their search fields today, but with this UI, it's important to synchronize the browser's search field with the SERP. Using JavaScript events to communicate removes some of the network latency. I think I'm missing some of the reasoning for the API. Could you perhaps clarify why Google ended up with
Re: [webkit-dev] SearchBox API
On Fri, Oct 15, 2010 at 10:10 AM, Darin Adler da...@apple.com wrote: On Oct 15, 2010, at 10:00 AM, Tony Gentilcore wrote: In any case, are there objections to beginning to land this under flag guard and vendor prefix? Yes, I do have an objection. Browser-specific API can be injected by the browser and doesn’t need to be built into WebKit. Safari already has some DOM API accessible only to search providers. WebKit has an architecture that allows this to be done without WebKit code changes. I suggest we put this feature in browsers, not the engine. Sorry to resurrect this old thread, but what are the DOM APIs in Safari that are accessible only to search providers? I searched around for a bit, but I couldn't find anything. Also nothing obvious jumped out at me either in the global scope or on window.navigator when I ran the inspector on my default search engine's results page. Thanks, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SearchBox API
Sorry to resurrect this old thread I presume you resurrected for other reasons, but I'll take the opportunity to give a brief update. The API is now implemented as a V8 extension in Chromium and documented here: http://dev.chromium.org/searchbox ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] SearchBox API
Hi All, We are working on adding instant search integration to Chrome. This requires a DOM API which only the default search provider has permission to access. As some of you may have seen, earlier this week I sent a proposal for such an API to the WHATWG [1]. Is this something that other ports might be interested in supporting in the future? In any case, are there objections to beginning to land this under flag guard and vendor prefix? -Tony [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-October/028818.html ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SearchBox API
On Oct 15, 2010, at 10:00 AM, Tony Gentilcore wrote: In any case, are there objections to beginning to land this under flag guard and vendor prefix? Yes, I do have an objection. Browser-specific API can be injected by the browser and doesn’t need to be built into WebKit. Safari already has some DOM API accessible only to search providers. WebKit has an architecture that allows this to be done without WebKit code changes. I suggest we put this feature in browsers, not the engine. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SearchBox API
http://googlesystem.blogspot.com/2010/09/instant-search-in-google-chrome.html would be more compelling with a video. :) I agree with Darin, this sounds like Browser-exposed DOM API. Not something that WebKit has any business adding. -eric On Fri, Oct 15, 2010 at 10:10 AM, Darin Adler da...@apple.com wrote: On Oct 15, 2010, at 10:00 AM, Tony Gentilcore wrote: In any case, are there objections to beginning to land this under flag guard and vendor prefix? Yes, I do have an objection. Browser-specific API can be injected by the browser and doesn’t need to be built into WebKit. Safari already has some DOM API accessible only to search providers. WebKit has an architecture that allows this to be done without WebKit code changes. I suggest we put this feature in browsers, not the engine. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SearchBox API
I think we're just coming at this from the point of view of trying to avoid UA-specific APIs exposed to web content. It seems risky to build APIs outside of WebKit that may be adopted by other UAs. We can certainly revisit this if that ever becomes reality. (Our current implementation exists on window.chrome.* by the way.) -Darin On Fri, Oct 15, 2010 at 10:24 AM, Eric Seidel e...@webkit.org wrote: http://googlesystem.blogspot.com/2010/09/instant-search-in-google-chrome.html would be more compelling with a video. :) I agree with Darin, this sounds like Browser-exposed DOM API. Not something that WebKit has any business adding. -eric On Fri, Oct 15, 2010 at 10:10 AM, Darin Adler da...@apple.com wrote: On Oct 15, 2010, at 10:00 AM, Tony Gentilcore wrote: In any case, are there objections to beginning to land this under flag guard and vendor prefix? Yes, I do have an objection. Browser-specific API can be injected by the browser and doesn’t need to be built into WebKit. Safari already has some DOM API accessible only to search providers. WebKit has an architecture that allows this to be done without WebKit code changes. I suggest we put this feature in browsers, not the engine. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SearchBox API
On Fri, Oct 15, 2010 at 10:28 AM, Darin Fisher da...@chromium.org wrote: I think we're just coming at this from the point of view of trying to avoid UA-specific APIs exposed to web content. It seems risky to build APIs outside of WebKit that may be adopted by other UAs. We can certainly revisit this if that ever becomes reality. (Our current implementation exists on window.chrome.* by the way.) -Darin On Fri, Oct 15, 2010 at 10:24 AM, Eric Seidel e...@webkit.org wrote: http://googlesystem.blogspot.com/2010/09/instant-search-in-google-chrome.html would be more compelling with a video. :) http://www.youtube.com/watch?v=tefRwthQaes shows an old version where the content didn't adjust to the dropdown size. You can play w/ it yourself on a windows dev channel build. I agree with Darin, this sounds like Browser-exposed DOM API. Not something that WebKit has any business adding. -eric On Fri, Oct 15, 2010 at 10:10 AM, Darin Adler da...@apple.com wrote: On Oct 15, 2010, at 10:00 AM, Tony Gentilcore wrote: In any case, are there objections to beginning to land this under flag guard and vendor prefix? Yes, I do have an objection. Browser-specific API can be injected by the browser and doesn’t need to be built into WebKit. Safari already has some DOM API accessible only to search providers. WebKit has an architecture that allows this to be done without WebKit code changes. I suggest we put this feature in browsers, not the engine. Okie. It sounds like the answer to my first question is an implied no. I'll keep in it Chrome for now. If this is ever something that other ports are interested in supporting, I'll still be happy to do the upstreaming work. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SearchBox API
Please correct me if I'm wrong, but I can't think of any features WebKit exposes which touch things outside of the WebView (the renderer view in Chrome). I guess window location and size? Maybe history? In general WebKit's job is limited to the box in which the web page is drawn. This feature is outside that box, and thus belongs outside of WebKit, correct? -eric On Fri, Oct 15, 2010 at 10:43 AM, Tony Gentilcore to...@chromium.org wrote: On Fri, Oct 15, 2010 at 10:28 AM, Darin Fisher da...@chromium.org wrote: I think we're just coming at this from the point of view of trying to avoid UA-specific APIs exposed to web content. It seems risky to build APIs outside of WebKit that may be adopted by other UAs. We can certainly revisit this if that ever becomes reality. (Our current implementation exists on window.chrome.* by the way.) -Darin On Fri, Oct 15, 2010 at 10:24 AM, Eric Seidel e...@webkit.org wrote: http://googlesystem.blogspot.com/2010/09/instant-search-in-google-chrome.html would be more compelling with a video. :) http://www.youtube.com/watch?v=tefRwthQaes shows an old version where the content didn't adjust to the dropdown size. You can play w/ it yourself on a windows dev channel build. I agree with Darin, this sounds like Browser-exposed DOM API. Not something that WebKit has any business adding. -eric On Fri, Oct 15, 2010 at 10:10 AM, Darin Adler da...@apple.com wrote: On Oct 15, 2010, at 10:00 AM, Tony Gentilcore wrote: In any case, are there objections to beginning to land this under flag guard and vendor prefix? Yes, I do have an objection. Browser-specific API can be injected by the browser and doesn’t need to be built into WebKit. Safari already has some DOM API accessible only to search providers. WebKit has an architecture that allows this to be done without WebKit code changes. I suggest we put this feature in browsers, not the engine. Okie. It sounds like the answer to my first question is an implied no. I'll keep in it Chrome for now. If this is ever something that other ports are interested in supporting, I'll still be happy to do the upstreaming work. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SearchBox API
I guess this particular feature may follow similar logic to the find-in-page support in WebKit. Although I think the browser still does most of the heavy-lifting for find-in-page. http://www.youtube.com/watch?v=tefRwthQaes seems to suggest this is entirely a browser feature. I'm not even sure why WebKit needs to be involved, since I would assume a browser would use a second-overlay WebView for the navigation preview. -eric On Fri, Oct 15, 2010 at 10:46 AM, Eric Seidel e...@webkit.org wrote: Please correct me if I'm wrong, but I can't think of any features WebKit exposes which touch things outside of the WebView (the renderer view in Chrome). I guess window location and size? Maybe history? In general WebKit's job is limited to the box in which the web page is drawn. This feature is outside that box, and thus belongs outside of WebKit, correct? -eric On Fri, Oct 15, 2010 at 10:43 AM, Tony Gentilcore to...@chromium.org wrote: On Fri, Oct 15, 2010 at 10:28 AM, Darin Fisher da...@chromium.org wrote: I think we're just coming at this from the point of view of trying to avoid UA-specific APIs exposed to web content. It seems risky to build APIs outside of WebKit that may be adopted by other UAs. We can certainly revisit this if that ever becomes reality. (Our current implementation exists on window.chrome.* by the way.) -Darin On Fri, Oct 15, 2010 at 10:24 AM, Eric Seidel e...@webkit.org wrote: http://googlesystem.blogspot.com/2010/09/instant-search-in-google-chrome.html would be more compelling with a video. :) http://www.youtube.com/watch?v=tefRwthQaes shows an old version where the content didn't adjust to the dropdown size. You can play w/ it yourself on a windows dev channel build. I agree with Darin, this sounds like Browser-exposed DOM API. Not something that WebKit has any business adding. -eric On Fri, Oct 15, 2010 at 10:10 AM, Darin Adler da...@apple.com wrote: On Oct 15, 2010, at 10:00 AM, Tony Gentilcore wrote: In any case, are there objections to beginning to land this under flag guard and vendor prefix? Yes, I do have an objection. Browser-specific API can be injected by the browser and doesn’t need to be built into WebKit. Safari already has some DOM API accessible only to search providers. WebKit has an architecture that allows this to be done without WebKit code changes. I suggest we put this feature in browsers, not the engine. Okie. It sounds like the answer to my first question is an implied no. I'll keep in it Chrome for now. If this is ever something that other ports are interested in supporting, I'll still be happy to do the upstreaming work. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SearchBox API
That's not really true. The whole network stack doesn't have anything to do with the box in which the web page is drawn. Neither do things like localStorage, but they all have DOM APIs. Adam On Fri, Oct 15, 2010 at 10:46 AM, Eric Seidel e...@webkit.org wrote: Please correct me if I'm wrong, but I can't think of any features WebKit exposes which touch things outside of the WebView (the renderer view in Chrome). I guess window location and size? Maybe history? In general WebKit's job is limited to the box in which the web page is drawn. This feature is outside that box, and thus belongs outside of WebKit, correct? -eric On Fri, Oct 15, 2010 at 10:43 AM, Tony Gentilcore to...@chromium.org wrote: On Fri, Oct 15, 2010 at 10:28 AM, Darin Fisher da...@chromium.org wrote: I think we're just coming at this from the point of view of trying to avoid UA-specific APIs exposed to web content. It seems risky to build APIs outside of WebKit that may be adopted by other UAs. We can certainly revisit this if that ever becomes reality. (Our current implementation exists on window.chrome.* by the way.) -Darin On Fri, Oct 15, 2010 at 10:24 AM, Eric Seidel e...@webkit.org wrote: http://googlesystem.blogspot.com/2010/09/instant-search-in-google-chrome.html would be more compelling with a video. :) http://www.youtube.com/watch?v=tefRwthQaes shows an old version where the content didn't adjust to the dropdown size. You can play w/ it yourself on a windows dev channel build. I agree with Darin, this sounds like Browser-exposed DOM API. Not something that WebKit has any business adding. -eric On Fri, Oct 15, 2010 at 10:10 AM, Darin Adler da...@apple.com wrote: On Oct 15, 2010, at 10:00 AM, Tony Gentilcore wrote: In any case, are there objections to beginning to land this under flag guard and vendor prefix? Yes, I do have an objection. Browser-specific API can be injected by the browser and doesn’t need to be built into WebKit. Safari already has some DOM API accessible only to search providers. WebKit has an architecture that allows this to be done without WebKit code changes. I suggest we put this feature in browsers, not the engine. Okie. It sounds like the answer to my first question is an implied no. I'll keep in it Chrome for now. If this is ever something that other ports are interested in supporting, I'll still be happy to do the upstreaming work. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SearchBox API
There’s no simple recipe to tell us what to build into WebKit and what goes into client applications. Explicit support for search fields and API directly related to the configuration of browser search has been left out of WebKit up until this point. Reasons for putting things into WebKit include things that have complicated interactions with other aspects of web technology, or are difficult to implement correctly and thus it’s good to share them among multiple WebKit clients. There’s no principle that would forbid starting to put technologies in WebKit to help implement features like APIs to control the search field or even other search field related features such as Safari’s search field snap back feature. On the other hand, just because API is exposed to websites does not on its own justify putting the API into the engine. I still stand my my original objection—this API should not go in WebKit at this time—but it’s not a simple black and white case of what can and can’t be in WebKit. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev