[webkit-dev] Client-based Geolocation
I've been working on getting Chromium's WebKit layer to support client-based Geolocation. This means that a class in the Chromium WebKit layer implements the WebCore interface GeolocationClient, and an instance of this class is provided to the Page constructor (by means of PageClients). This is a neat way of keeping the platform specific code in the WebKit layer (rather than in WebCore, where the existing GeolocationService and platform code is). The design of client-based geolocation feels very clean and I think it is easier to understand as it follows a similar pattern to other existing client-based designs (e.g. speech, device orientation, device motion). It would be great if, ultimately, we could remove the non-client-based geolocation code from WebCore (I already have plans to do this for Chromium's WebKit layer). Such a removal would make the WebCore code more readable because the #if ENABLE(CLIENT_BASED_GEOLOCATION) preprocessor directives would go away, more understandable because there would be less code, and more maintainable because we would only need to fix bugs in one code path, rather than two. It seems that Android, Qt and GTK currently implement the non-client-based design. Is anybody working, or interested in working, on migrating these platforms to the client-based design? Thanks John ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKitTools is changing to Tools
Is it time to throw the switch now? Adam On Sun, Nov 21, 2010 at 9:55 AM, Dan Bernstein m...@apple.com wrote: On Nov 21, 2010, at 5:41 AM, Eric Seidel wrote: That's likely to break all the ews and commit bots. Since I'm on vacation at least the ones I run will remain broken until I return on 29th. Thanks for letting me know. I will make this change some other time. On Nov 21, 2010 2:31 AM, Dan Bernstein m...@apple.com wrote: WebKit developers, I am going to commit the patch from https://bugs.webkit.org/show_bug.cgi?id=49861, renaming the WebKitTools directory to Tools and updating all internal references. If you update your tree after that, you might need to adjust any personal scripts or tools that refer to the old name. I am planning to do this in ~14 hours from now (9:30PM UTC, 1:30PM PST). Regards, —Dan ___ 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] Rebaselining render tree dumps
On Wed, Dec 8, 2010 at 11:04 PM, Nikolas Zimmermann zimmerm...@physik.rwth-aachen.de wrote: Hi Ryosuke, this feature is already available. I've implemented it for the svg/dynamic-updates test, DRT hooks are available. dumpAsText() takes an optional boolean parameter that toggles this. // svg/dynamic-updates tests set enablePixelTesting=true, as we want to dump text + pixel results if (window.layoutTestController) layoutTestController.dumpAsText(true /* enablePixelTesting */); That will give you a dumpAsText result + a pixel test result. Hope that helps.. I didn't know that! This will be very useful for a lot of tests. In fact, why don't we convert tests as we rebaseline? If Ahem allows us to have the same pixel expected results for all platforms. Why don't we switch the default font o DRT to Ahem? - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Rebaselining render tree dumps
On Dec 10, 2010, at 2:05 PM, Ryosuke Niwa wrote: If Ahem allows us to have the same pixel expected results for all platforms. Why don't we switch the default font of DRT to Ahem? Ahem is a testing font where characters are all boxes. It’s quite useful for testing text layout that involves characters in a way that’s not font-metric-specific, but for more general purpose tests, it has the problem that the text is not readable. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKitTools is changing to Tools
On Dec 10, 2010, at 5:21 PM, Eric Seidel wrote: Could we add a symlink before then? That seems unlikely to work on Windows, though if the only processes that rely on the symlink are Cygwin-based, maaybe it will. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKitTools is changing to Tools
That's fine. We'll move the non-windows bots over. :) On Fri, Dec 10, 2010 at 2:23 PM, Adam Roben aro...@apple.com wrote: On Dec 10, 2010, at 5:21 PM, Eric Seidel wrote: Could we add a symlink before then? That seems unlikely to work on Windows, though if the only processes that rely on the symlink are Cygwin-based, maaybe it will. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKitTools is changing to Tools
I have an all-day meeting that day so I'm not sure if I'll be free by 4pm PST. But the changes on the master are simple, so I could easily do them sometime that evening if not right at 4pm. Slave machines should not need to restart. -Bill On Dec 10, 2010, at 2:21 PM, Eric Seidel wrote: I suspect there will be a lot of follow-on cleanup. I don't plan to be hacking much that evening, but it would be possible. grep -l -r WebKitTools * | grep -v pyc | grep -v ChangeLog Shows that at least 65 files in svn.webkit.org will need an update. I expect all of the queues.webkit.org bots will need restarts. As well as possibly build.webkit.org bots as well. So that means at least the following people will need to perform restarts: - me (cq nodes, and ews) - Adam Barth (cq nodes, and ews) - Bill Siegrist (build.webkit.org) - Lucas Forschler (win ews nodes) - Lucas De Marchi (EFL ews) - Whoever runs the Qt ews I don't think the build slaves will need to be restarted, right Bill? I'm all for the change, but ideally we should come up with a list of who all will be affected (that may just be the list above?) Could we add a symlink before then? Then it would be easy for most of those restarts to happen before the switch date. -eric On Fri, Dec 10, 2010 at 2:10 PM, Dan Bernstein m...@apple.com wrote: On Dec 10, 2010, at 1:58 PM, Adam Barth aba...@webkit.org wrote: Is it time to throw the switch now? How about next week, Dec 17 at around 4PM PST? Adam On Sun, Nov 21, 2010 at 9:55 AM, Dan Bernstein m...@apple.com wrote: On Nov 21, 2010, at 5:41 AM, Eric Seidel wrote: That's likely to break all the ews and commit bots. Since I'm on vacation at least the ones I run will remain broken until I return on 29th. Thanks for letting me know. I will make this change some other time. On Nov 21, 2010 2:31 AM, Dan Bernstein m...@apple.com wrote: WebKit developers, I am going to commit the patch from https://bugs.webkit.org/show_bug.cgi?id=49861, renaming the WebKitTools directory to Tools and updating all internal references. If you update your tree after that, you might need to adjust any personal scripts or tools that refer to the old name. I am planning to do this in ~14 hours from now (9:30PM UTC, 1:30PM PST). Regards, —Dan ___ 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] WebKitTools is changing to Tools
On Dec 10, 2010, at 2:21 PM, Eric Seidel wrote: I suspect there will be a lot of follow-on cleanup. I don't plan to be hacking much that evening, but it would be possible. grep -l -r WebKitTools * | grep -v pyc | grep -v ChangeLog Shows that at least 65 files in svn.webkit.org will need an update. I don’t understand. Aren’t those files covered by my patch at https://bugs.webkit.org/show_bug.cgi?id=49861 ? I expect all of the queues.webkit.org bots will need restarts. As well as possibly build.webkit.org bots as well. So that means at least the following people will need to perform restarts: - me (cq nodes, and ews) - Adam Barth (cq nodes, and ews) - Bill Siegrist (build.webkit.org) - Lucas Forschler (win ews nodes) - Lucas De Marchi (EFL ews) - Whoever runs the Qt ews I don't think the build slaves will need to be restarted, right Bill? I'm all for the change, but ideally we should come up with a list of who all will be affected (that may just be the list above?) Could we add a symlink before then? Yes, unless that creates problems for some non-Unix platforms. Then it would be easy for most of those restarts to happen before the switch date. -eric On Fri, Dec 10, 2010 at 2:10 PM, Dan Bernstein m...@apple.com wrote: On Dec 10, 2010, at 1:58 PM, Adam Barth aba...@webkit.org wrote: Is it time to throw the switch now? How about next week, Dec 17 at around 4PM PST? Adam On Sun, Nov 21, 2010 at 9:55 AM, Dan Bernstein m...@apple.com wrote: On Nov 21, 2010, at 5:41 AM, Eric Seidel wrote: That's likely to break all the ews and commit bots. Since I'm on vacation at least the ones I run will remain broken until I return on 29th. Thanks for letting me know. I will make this change some other time. On Nov 21, 2010 2:31 AM, Dan Bernstein m...@apple.com wrote: WebKit developers, I am going to commit the patch from https://bugs.webkit.org/show_bug.cgi?id=49861, renaming the WebKitTools directory to Tools and updating all internal references. If you update your tree after that, you might need to adjust any personal scripts or tools that refer to the old name. I am planning to do this in ~14 hours from now (9:30PM UTC, 1:30PM PST). Regards, —Dan ___ 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] WebKitTools is changing to Tools
On Fri, Dec 10, 2010 at 2:38 PM, Dan Bernstein m...@apple.com wrote: On Dec 10, 2010, at 2:21 PM, Eric Seidel wrote: I suspect there will be a lot of follow-on cleanup. I don't plan to be hacking much that evening, but it would be possible. grep -l -r WebKitTools * | grep -v pyc | grep -v ChangeLog Shows that at least 65 files in svn.webkit.org will need an update. I don’t understand. Aren’t those files covered by my patch at https://bugs.webkit.org/show_bug.cgi?id=49861 ? Yes, sorry, I didn't mean to imply they wouldnt' be covered. I was just stating the count after looking at the list myself to try and understand the server (and thus people) impact. I expect all of the queues.webkit.org bots will need restarts. As well as possibly build.webkit.org bots as well. So that means at least the following people will need to perform restarts: - me (cq nodes, and ews) - Adam Barth (cq nodes, and ews) - Bill Siegrist (build.webkit.org) - Lucas Forschler (win ews nodes) - Lucas De Marchi (EFL ews) - Whoever runs the Qt ews I don't think the build slaves will need to be restarted, right Bill? I'm all for the change, but ideally we should come up with a list of who all will be affected (that may just be the list above?) Could we add a symlink before then? Yes, unless that creates problems for some non-Unix platforms. Then it would be easy for most of those restarts to happen before the switch date. -eric On Fri, Dec 10, 2010 at 2:10 PM, Dan Bernstein m...@apple.com wrote: On Dec 10, 2010, at 1:58 PM, Adam Barth aba...@webkit.org wrote: Is it time to throw the switch now? How about next week, Dec 17 at around 4PM PST? Adam On Sun, Nov 21, 2010 at 9:55 AM, Dan Bernstein m...@apple.com wrote: On Nov 21, 2010, at 5:41 AM, Eric Seidel wrote: That's likely to break all the ews and commit bots. Since I'm on vacation at least the ones I run will remain broken until I return on 29th. Thanks for letting me know. I will make this change some other time. On Nov 21, 2010 2:31 AM, Dan Bernstein m...@apple.com wrote: WebKit developers, I am going to commit the patch from https://bugs.webkit.org/show_bug.cgi?id=49861, renaming the WebKitTools directory to Tools and updating all internal references. If you update your tree after that, you might need to adjust any personal scripts or tools that refer to the old name. I am planning to do this in ~14 hours from now (9:30PM UTC, 1:30PM PST). Regards, —Dan ___ 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] Looking for a V8 bindings volunteer to fix setLocation, open, and showModalDialog
Hi folks. I’m moved the logic of setLocation, open, and showModalDialog out of the JavaScript bindings and into the DOMWindow class. http://trac.webkit.org/changeset/73647 http://trac.webkit.org/changeset/73660 http://trac.webkit.org/changeset/73829 I was hoping to find a volunteer to change the V8 bindings to use the DOMWindow version. Anyone up for it? -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Looking for a V8 bindings volunteer to fix setLocation, open, and showModalDialog
Sure. On Fri, Dec 10, 2010 at 6:21 PM, Darin Adler da...@apple.com wrote: Hi folks. I’m moved the logic of setLocation, open, and showModalDialog out of the JavaScript bindings and into the DOMWindow class. http://trac.webkit.org/changeset/73647 http://trac.webkit.org/changeset/73660 http://trac.webkit.org/changeset/73829 I was hoping to find a volunteer to change the V8 bindings to use the DOMWindow version. Anyone up for it? -- 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] Rebaselining render tree dumps
On Fri, Dec 10, 2010 at 2:21 PM, Darin Adler da...@apple.com wrote: On Dec 10, 2010, at 2:05 PM, Ryosuke Niwa wrote: If Ahem allows us to have the same pixel expected results for all platforms. Why don't we switch the default font of DRT to Ahem? Ahem is a testing font where characters are all boxes. It’s quite useful for testing text layout that involves characters in a way that’s not font-metric-specific, but for more general purpose tests, it has the problem that the text is not readable. Thanks for the response. Yeah, I was quite ignorant about this. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Fwd: how to extend self-defined javascript in webkit using v8 on android
Hi all, I want to extend my javascript in webpage on android, eg. var myObj = new MYOBJ(); myObj.x =3, according to v8 guide and webkit sourcecode. the former guide us to write standalone v8-based application, and the later the target to extend. I found that the binding from domwindow object to v8domwindow is auto generated by scripts, then I met problem when I try to add customized javascript to the webcore, for example , In the webcore, DOM binding will create a context , where specified Frame related extensions and objecttemplate , it seems that I could v8::RegisterExtension and add objecttemplate to the exisited context enviroment in order binding my customzied MYOBJ to v8, is it the correct idea?and how can I add my objecttemplate for MYOBJ to the exisit on for webcore's DOM, please give me some hint or example on this ,thank you! Volter ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Client-based Geolocation
On Dec 10, 2010, at 6:45 AM, John Knottenbelt jknot...@chromium.org wrote: It would be great if, ultimately, we could remove the non-client-based geolocation code from WebCore (I already have plans to do this for Chromium's WebKit layer). Such a removal would make the WebCore code more readable because the #if ENABLE(CLIENT_BASED_GEOLOCATION) preprocessor directives would go away, more understandable because there would be less code, and more maintainable because we would only need to fix bugs in one code path, rather than two. It seems that Android, Qt and GTK currently implement the non-client-based design. The iOS port also uses the non-client-based design. Is anybody working, or interested in working, on migrating these platforms to the client-based design? I would file a bug for each port to start with. Dave -- Sent from my iPhone 4 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
