Re: [webkit-dev] Flaky test hit list
BTW, the commit-queue has started complaining publicly about flaky tests: https://bugs.webkit.org/show_bug.cgi?id=47698#c5 Hopefully this will bring further awareness to the issue. Test flakes are the second most common reason for delays with the commit-queue (after the Snow Leopard build being broken). -eric p.s. Eventually we may improve the commit-queue to know how to file bugs against flaky tests itself. On Fri, Oct 1, 2010 at 7:29 AM, Adam Barth aba...@webkit.org wrote: 2010/10/1 Fumitoshi Ukai (鵜飼文敏) u...@chromium.org: On Fri, Oct 1, 2010 at 12:03, Adam Barth aba...@webkit.org wrote: https://bugs.webkit.org/show_bug.cgi?id=46956 Unfortunately, it doesn't solve the whole problem. It does seem to reduce the flakiness by a lot though. Thanks! I think it might be race between DRT and pywebsocekt server, that is, DRT tries to run tests while pywebsocket server is still initializing and not yet ready to serve html. I'll try to fix pywebsocket to reduce initialization latency. That doesn't seem that likely. With my patch, this happens after running something like 2000 WebSockets. It doesn't feel like an initialization race to me. It feels more like the the WebSocket server is dropping a connection once in a while. Adam ___ 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] 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
Re: [webkit-dev] Selection Highlight and MathML
Do the objects actually overlap each other? dave On Oct 14, 2010, at 8:58 PM, Alex Milowski wrote: On Thu, Oct 14, 2010 at 5:19 PM, Darin Adler da...@apple.com wrote: On Oct 14, 2010, at 2:12 PM, Alex Milowski wrote: I'm curious as to why MathML seems to be treated differently for selection highlights. Differently from what? I’m not sure what your question is. If you try out the attachment from the bug you'll see what I mean. Essentially, MathML seems to get several overlapping highlights that get darker and darker the more that they overlap via several layers. As such, the content eventually gets washed out by the highlight color. I do not see this behavior for non-MathML content and that leads me to believe we need to something in the rendering objects for MathML. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ 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] Selection Highlight and MathML
On Fri, Oct 15, 2010 at 11:43 AM, David Hyatt hy...@apple.com wrote: Do the objects actually overlap each other? Yes. Most of the overlap comes from containment (e.g. inline blocks containing other constructs. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Odd Build Issue on Gtk Port
On Fri, Oct 15, 2010 at 3:34 PM, Martin Robinson martin.james.robin...@gmail.com wrote: On Fri, Oct 15, 2010 at 3:32 PM, Evan Martin e...@chromium.org wrote: gdk_display_get_default() has been available since 2.2, which is older than anything still around. You should probably fix the call site rather than doing this header tweak. I concur. Ideally GtkVersioning.h should be used for API that exists in newer versions of GTK and not older ones. OK. This is not my area of expertise. I just hacked my way through it to get a working version. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
