Re: [webkit-dev] build.webkit.org down for upgrade
Lucas Forschler írta: to 0.8.6p1 Will be back online when complete. Lucas Hi All, Unfortunately there are too annoying bugs introduced with upgrading build master to 0.8.6p1 : Problem 1 -- Builders are alphabetically ordered on http://build.webkit.org/waterfall instead of the given order in our config.json. http://buildbot.net/buildbot/docs/0.8.6p1/release-notes.html Builders are no longer displayed in the order they were configured. This was never intended behavior, and will become impossible in the distributed architecture planned for Buildbot-0.9.x. As of 0.8.6p1, builders are sorted naturally: lexically, but with numeric segments sorted numerically. I think the new alphabetical order is so confusing. For example Apple's Lion bots are between GTK and Qt bots, but SnowLeopard bots are after the Qt bots. I know that we can see category=AppleMac, category=Qt, ... , but the order of the bots in a given category is important for us too. I don't think that an artifical renaming would be a good solution to get the order what we want. (Because we would have to rename bots in all scripts, we would have loose the history, ...) What about if we revert the buildbot-0.8.6p1 change in buildmaster caused this bug/feature? Here is a simple patch to do it: diff --git a/buildbot-0.8.6p1/buildbot/status/master.py b/buildbot-0.8.6p1/buildbot/status/master.py index e803133..e60ab06 100644 --- a/buildbot-0.8.6p1/buildbot/status/master.py +++ b/buildbot-0.8.6p1/buildbot/status/master.py @@ -200,7 +200,7 @@ class Status(config.ReconfigurableServiceMixin, service.MultiService): def getBuilderNames(self, categories=None): if categories == None: -return util.naturalSort(self.botmaster.builderNames) # don't let them break it +return self.botmaster.builderNames # don't let them break it l = [] # respect addition order @@ -208,7 +208,7 @@ class Status(config.ReconfigurableServiceMixin, service.MultiService): bldr = self.botmaster.builders[name] if bldr.config.category in categories: l.append(name) -return util.naturalSort(l) +return l def getBuilder(self, name): Problem 2 -- There isn't force build possibility anymore. http://buildbot.net/buildbot/docs/0.8.6p1/release-notes.html Forced builds now require that a ForceScheduler be defined in the Buildbot configuration. It can be solved simple with adding ForceScheduler. I'm going to file a bug report and prepare a patch to fix it soon. br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] build.webkit.org down for upgrade
HI Ossy, I did notice the display order change as well. I think I am going to open a bug to rename all of the Apple bots to prefix them with 'Apple'. We (at Apple) would like to get our bots into a more conforming naming convention. I realize that won't solve the problem with having a specific order for your bots, but it will at least get everything grouped together. I'm slightly opposed to rolling out the natural sorting as you suggest below… I think that will be short-lived and when buildbot 0.9.x is available, we may not have this option. I think we should be forward thinking here and try not to work around this. I can be convinced to make the change if there is additional support for rolling out the natural sorting. Thanks for looking into the ForceScheduler. Hopefully we can get that up and running quickly. So far it appears we don't have any bots stuck in trigger mode. Please let me know if you see any. I am hoping that issue is now solved for good. Thanks, Lucas On May 31, 2012, at 3:32 AM, Osztrogonac Csaba wrote: Lucas Forschler írta: to 0.8.6p1 Will be back online when complete. Lucas Hi All, Unfortunately there are too annoying bugs introduced with upgrading build master to 0.8.6p1 : Problem 1 -- Builders are alphabetically ordered on http://build.webkit.org/waterfall instead of the given order in our config.json. http://buildbot.net/buildbot/docs/0.8.6p1/release-notes.html Builders are no longer displayed in the order they were configured. This was never intended behavior, and will become impossible in the distributed architecture planned for Buildbot-0.9.x. As of 0.8.6p1, builders are sorted naturally: lexically, but with numeric segments sorted numerically. I think the new alphabetical order is so confusing. For example Apple's Lion bots are between GTK and Qt bots, but SnowLeopard bots are after the Qt bots. I know that we can see category=AppleMac, category=Qt, ... , but the order of the bots in a given category is important for us too. I don't think that an artifical renaming would be a good solution to get the order what we want. (Because we would have to rename bots in all scripts, we would have loose the history, ...) What about if we revert the buildbot-0.8.6p1 change in buildmaster caused this bug/feature? Here is a simple patch to do it: diff --git a/buildbot-0.8.6p1/buildbot/status/master.py b/buildbot-0.8.6p1/buildbot/status/master.py index e803133..e60ab06 100644 --- a/buildbot-0.8.6p1/buildbot/status/master.py +++ b/buildbot-0.8.6p1/buildbot/status/master.py @@ -200,7 +200,7 @@ class Status(config.ReconfigurableServiceMixin, service.MultiService): def getBuilderNames(self, categories=None): if categories == None: -return util.naturalSort(self.botmaster.builderNames) # don't let them break it +return self.botmaster.builderNames # don't let them break it l = [] # respect addition order @@ -208,7 +208,7 @@ class Status(config.ReconfigurableServiceMixin, service.MultiService): bldr = self.botmaster.builders[name] if bldr.config.category in categories: l.append(name) -return util.naturalSort(l) +return l def getBuilder(self, name): Problem 2 -- There isn't force build possibility anymore. http://buildbot.net/buildbot/docs/0.8.6p1/release-notes.html Forced builds now require that a ForceScheduler be defined in the Buildbot configuration. It can be solved simple with adding ForceScheduler. I'm going to file a bug report and prepare a patch to fix it soon. br, Ossy ___ 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] webkit2 with v8
I continued to work on this, more complete patches have been sent in https://bugs.webkit.org/show_bug.cgi?id=87872 and https://bugs.webkit.org/show_bug.cgi?id=84457. It's not because I don't understand your points, but it's better to debate on an actual patch that just theoretically :) I think most of what is needed in WebKit2 to support v8 is really just boilerplate code that should not change regularly. On 04/24/2012 12:23 AM, Sam Weinig wrote: Without considerable more demand, I don't think we want this. -Sam On Apr 23, 2012, at 3:20 PM, Balazs Kelemenkbal...@webkit.org wrote: On 04/23/2012 11:53 PM, Sam Weinig wrote: Hi Balazs, This is something we don't want at this time. Dealing with V8 in WebCore is pretty big maintenance burden and one I would rather not have in WebKit2 unless there is considerable demand for it. Well, it's important for Qt. In your patch (attached to https://bugs.webkit.org/show_bug.cgi?id=84457), there are many intrusive changes to core WebKit2 code, making it harder to comprehend and refactor. Also, since a much bigger proportion of developers who develop WebKit2 don't ever compile V8, it seems more likely that the code will stop working. The WIP patch I uploaded is just a very first step to make it possible to build with v8 without breaking the most basic features. I have just overhacked every problematic part - instead of finding a proper solution to them - to see how many dependencies there are on JSC as quickly as possible. It should be way better before uploaded for review. -Sam On Apr 23, 2012, at 3:28 AM, Balazs Kelemenkbal...@webkit.org wrote: Hi everyone, I would like to inform you about the topic I am working on, since it is something that can affect WebKit2 architecturally. I would like to make WebKit2 work with v8. The motivation behind this is that the long term goal of the Qt port is to switch to v8. Qt already use v8 in it's Qml module, and it's better to have only one VM in the framework (less code size, less memory usage, easier maintenance). My goal is to achieve this with the minimal amount of changes made in WebKit2. My plan for WebKitTestRunner is to wrap v8 behind the JavaScriptCore API (or, in another point of view, implement the JSC API upon the v8 API). For the core of WebKit2 we will have to use some bindings for things like plugins or the injected bundle but it should be not too much of a maintenance burden. Inform me if you have any concerns or suggestion. Cheers! Balazs Kelemen ___ 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] webkit2 with v8
What I'm seeing is that parts of v8 support are already leaking into cross-platform WebKit2 code. WebKitTestRunner cannot just use WebCoreTestSupport, it needs an ifdef for Qt: #if PLATFORM(QT) DumpRenderTreeSupportQt::injectInternalsObject(context); #else WebCoreTestSupport::injectInternalsObject(context); #endif This is of course something non-Qt developers have to worry about, see e.g. https://bugs.webkit.org/show_bug.cgi?id=87783#c14. - WBR, Alexey Proskuryakov 31.05.2012, в 9:38, Balazs Kelemen написал(а): I continued to work on this, more complete patches have been sent in https://bugs.webkit.org/show_bug.cgi?id=87872 and https://bugs.webkit.org/show_bug.cgi?id=84457. It's not because I don't understand your points, but it's better to debate on an actual patch that just theoretically :) I think most of what is needed in WebKit2 to support v8 is really just boilerplate code that should not change regularly. On 04/24/2012 12:23 AM, Sam Weinig wrote: Without considerable more demand, I don't think we want this. -Sam On Apr 23, 2012, at 3:20 PM, Balazs Kelemen kbal...@webkit.org wrote: On 04/23/2012 11:53 PM, Sam Weinig wrote: Hi Balazs, This is something we don't want at this time. Dealing with V8 in WebCore is pretty big maintenance burden and one I would rather not have in WebKit2 unless there is considerable demand for it. Well, it's important for Qt. In your patch (attached to https://bugs.webkit.org/show_bug.cgi?id=84457), there are many intrusive changes to core WebKit2 code, making it harder to comprehend and refactor. Also, since a much bigger proportion of developers who develop WebKit2 don't ever compile V8, it seems more likely that the code will stop working. The WIP patch I uploaded is just a very first step to make it possible to build with v8 without breaking the most basic features. I have just overhacked every problematic part - instead of finding a proper solution to them - to see how many dependencies there are on JSC as quickly as possible. It should be way better before uploaded for review. -Sam On Apr 23, 2012, at 3:28 AM, Balazs Kelemenkbal...@webkit.org wrote: Hi everyone, I would like to inform you about the topic I am working on, since it is something that can affect WebKit2 architecturally. I would like to make WebKit2 work with v8. The motivation behind this is that the long term goal of the Qt port is to switch to v8. Qt already use v8 in it's Qml module, and it's better to have only one VM in the framework (less code size, less memory usage, easier maintenance). My goal is to achieve this with the minimal amount of changes made in WebKit2. My plan for WebKitTestRunner is to wrap v8 behind the JavaScriptCore API (or, in another point of view, implement the JSC API upon the v8 API). For the core of WebKit2 we will have to use some bindings for things like plugins or the injected bundle but it should be not too much of a maintenance burden. Inform me if you have any concerns or suggestion. Cheers! Balazs Kelemen ___ 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] build.webkit.org down for upgrade
On the other hand, this looks like a regression. Can we file a bug against buildbot and see what they have to say about it? On May 31, 2012 9:22 AM, Lucas Forschler lforsch...@apple.com wrote: HI Ossy, I did notice the display order change as well. I think I am going to open a bug to rename all of the Apple bots to prefix them with 'Apple'. We (at Apple) would like to get our bots into a more conforming naming convention. I realize that won't solve the problem with having a specific order for your bots, but it will at least get everything grouped together. I'm slightly opposed to rolling out the natural sorting as you suggest below… I think that will be short-lived and when buildbot 0.9.x is available, we may not have this option. I think we should be forward thinking here and try not to work around this. I can be convinced to make the change if there is additional support for rolling out the natural sorting. Thanks for looking into the ForceScheduler. Hopefully we can get that up and running quickly. So far it appears we don't have any bots stuck in trigger mode. Please let me know if you see any. I am hoping that issue is now solved for good. Thanks, Lucas On May 31, 2012, at 3:32 AM, Osztrogonac Csaba wrote: Lucas Forschler írta: to 0.8.6p1 Will be back online when complete. Lucas Hi All, Unfortunately there are too annoying bugs introduced with upgrading build master to 0.8.6p1 : Problem 1 -- Builders are alphabetically ordered on http://build.webkit.org/waterfall instead of the given order in our config.json. http://buildbot.net/buildbot/docs/0.8.6p1/release-notes.html Builders are no longer displayed in the order they were configured. This was never intended behavior, and will become impossible in the distributed architecture planned for Buildbot-0.9.x. As of 0.8.6p1, builders are sorted naturally: lexically, but with numeric segments sorted numerically. I think the new alphabetical order is so confusing. For example Apple's Lion bots are between GTK and Qt bots, but SnowLeopard bots are after the Qt bots. I know that we can see category=AppleMac, category=Qt, ... , but the order of the bots in a given category is important for us too. I don't think that an artifical renaming would be a good solution to get the order what we want. (Because we would have to rename bots in all scripts, we would have loose the history, ...) What about if we revert the buildbot-0.8.6p1 change in buildmaster caused this bug/feature? Here is a simple patch to do it: diff --git a/buildbot-0.8.6p1/buildbot/status/master.py b/buildbot-0.8.6p1/buildbot/status/master.py index e803133..e60ab06 100644 --- a/buildbot-0.8.6p1/buildbot/status/master.py +++ b/buildbot-0.8.6p1/buildbot/status/master.py @@ -200,7 +200,7 @@ class Status(config.ReconfigurableServiceMixin, service.MultiService): def getBuilderNames(self, categories=None): if categories == None: -return util.naturalSort(self.botmaster.builderNames) # don't let them break it +return self.botmaster.builderNames # don't let them break it l = [] # respect addition order @@ -208,7 +208,7 @@ class Status(config.ReconfigurableServiceMixin, service.MultiService): bldr = self.botmaster.builders[name] if bldr.config.category in categories: l.append(name) -return util.naturalSort(l) +return l def getBuilder(self, name): Problem 2 -- There isn't force build possibility anymore. http://buildbot.net/buildbot/docs/0.8.6p1/release-notes.html Forced builds now require that a ForceScheduler be defined in the Buildbot configuration. It can be solved simple with adding ForceScheduler. I'm going to file a bug report and prepare a patch to fix it soon. br, Ossy ___ 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] testharness Wiki page added
I added the following Wiki page to provide some information on testharness.js (the JavaScript framework from W3C recently landed in WebKit): http://trac.webkit.org/wiki/Writing%20testharness%20Tests I also updated the text under Writing JavaScript-based DOM only test cases on this page http://trac.webkit.org/wiki/Writing%20Layout%20Tests%20for%20DumpRenderTree. Note that I am recommending the use of testharness.js / testharnessreport.js over js-test-pre.js/js-test-post.js, when applicable, since tests written using testharness can be copied to the W3C test repository with only minor changes. Please review and send me any feedback on these pages. I am considering adding a detailed example to the testharness wiki page to demonstrate how the API should be used. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] testharness Wiki page added
On Thu, May 31, 2012 at 11:18 AM, Jacob Goldstein jac...@adobe.com wrote: I added the following Wiki page to provide some information on testharness.js (the JavaScript framework from W3C recently landed in WebKit): http://trac.webkit.org/wiki/Writing%20testharness%20Tests I also updated the text under Writing JavaScript-based DOM only test cases on this page http://trac.webkit.org/wiki/Writing%20Layout%20Tests%20for%20DumpRenderTree. Note that I am recommending the use of testharness.js / testharnessreport.js *over* js-test-pre.js/js-test-post.js, when applicable, since tests written using testharness can be copied to the W3C test repository with only minor changes. Note that this isn't true once we start using layoutTestController in the test. Tests that we currently use LTC such as to invoke mouse events, keyboard events, etc... are currently manual tests in W3C test suites. They use meta elements to tag manual tests but the actual instruction is just regular English sentences. It would be good to codify this information so that we can automate some of W3C manual tests at least in WebKit. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] We should rename layoutTestController to testController
I am thinking we should rename layoutTestController to testController. Or if you don’t like that name, maybe testHarness or some even better name. The old name is too long and the word “layout” is so strange. We could expose the object under the new name and the old one, and then over time convert all the tests to the new name, then get rid of the old one. What do you all think? -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] We should rename layoutTestController to testController
On 5/31/12 11:56 AM, Darin Adler da...@apple.com wrote: I am thinking we should rename layoutTestController to testController. Or if you don¹t like that name, maybe testHarness or some even better name. testHarness is probably not a good choice as the W3C JavaScript framework that recently landed in WebKit, and that we are going to encourage people to use for DOM-only tests, is called testharness.js The old name is too long and the word ³layout² is so strange. We could expose the object under the new name and the old one, and then over time convert all the tests to the new name, then get rid of the old one. What do you all think? -- 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] We should rename layoutTestController to testController
testController seems fine to me. I agree it's an improvement. On the other hand there are other tasks that have more benefit in terms of code maintenance for people wanting to spend time working in this area. A couple ideas: - Move more APIs that only depend WebCore code to internals. Reduces code duplication and complexity. - Work on exposing things like eventSender through an NPAPI plugin. That way it can be shared across browser vendors and could be used by the W3C test harness as well. This would be for APIs that we want for testing but don't make sense to expose to the web. Ojan On Thu, May 31, 2012 at 11:56 AM, Darin Adler da...@apple.com wrote: I am thinking we should rename layoutTestController to testController. Or if you don’t like that name, maybe testHarness or some even better name. The old name is too long and the word “layout” is so strange. We could expose the object under the new name and the old one, and then over time convert all the tests to the new name, then get rid of the old one. What do you all think? -- 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] We should rename layoutTestController to testController
On Thu, May 31, 2012 at 11:56 AM, Darin Adler da...@apple.com wrote: I am thinking we should rename layoutTestController to testController. Or if you don’t like that name, maybe testHarness or some even better name. testController seems like a misnomer since it doesn't really control the test itself. I would prefer testRunnerController or simply testRunner since it's quite self-evident that methods on testRunner would act on the test runner itself. We could expose the object under the new name and the old one, and then over time convert all the tests to the new name, then get rid of the old one. That sounds like a good idea. Can we also rename LayoutTests to RegressionTests? I know Dave (Hyatt) suggested to cleanup the render tree dump format to get rid of all hacks and tweaks we've added over years, and my preference is to combine all these efforts and put new types of tests in trunk/RegressionTests. We'll move tests from LayoutTests to RegressionTests as we convert. We'll get rid of LayoutTests directory once all tests have been converted to use testRunner and new render tree dump format. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] We should rename layoutTestController to testController
On Thu, May 31, 2012 at 12:07 PM, Ojan Vafai o...@chromium.org wrote: testController seems fine to me. I agree it's an improvement. On the other hand there are other tasks that have more benefit in terms of code maintenance for people wanting to spend time working in this area. A couple ideas: - Move more APIs that only depend WebCore code to internals. Reduces code duplication and complexity. - Work on exposing things like eventSender through an NPAPI plugin. That way it can be shared across browser vendors and could be used by the W3C test harness as well. This would be for APIs that we want for testing but don't make sense to expose to the web. W3C is developing a WebDriver specification which tries to automate tests that require mouse/keyboard events, etc...: https://dvcs.w3.org/hg/webdriver/raw-file/tip/webdriver-spec.html If we're trying to share code across browser vendors, then we should probably use this API instead. I suspect we can emulate the most of API surface using eventSender even if we could not natively support it. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] We should rename layoutTestController to testController
On May 31, 2012, at 12:11 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, May 31, 2012 at 11:56 AM, Darin Adler da...@apple.com wrote: I am thinking we should rename layoutTestController to testController. Or if you don’t like that name, maybe testHarness or some even better name. testController seems like a misnomer since it doesn't really control the test itself. I would prefer testRunnerController or simply testRunner since it's quite self-evident that methods on testRunner would act on the test runner itself. I like the name testRunner. We could expose the object under the new name and the old one, and then over time convert all the tests to the new name, then get rid of the old one. That sounds like a good idea. Can we also rename LayoutTests to RegressionTests? I know Dave (Hyatt) suggested to cleanup the render tree dump format to get rid of all hacks and tweaks we've added over years, and my preference is to combine all these efforts and put new types of tests in trunk/RegressionTests. We'll move tests from LayoutTests to RegressionTests as we convert. We'll get rid of LayoutTests directory once all tests have been converted to use testRunner and new render tree dump format. - Ryosuke ___ 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] [webkit-changes] [119113] trunk/Source/WebKit/gtk
On May 31, 2012, at 9:36 AM, commit-qu...@webkit.org wrote: Revision 119113 Author commit-qu...@webkit.org Date 2012-05-31 09:36:29 -0700 (Thu, 31 May 2012) Modified: trunk/Source/WebKit/gtk/ChangeLog (119112 = 119113) --- trunk/Source/WebKit/gtk/ChangeLog 2012-05-31 16:32:33 UTC (rev 119112) +++ trunk/Source/WebKit/gtk/ChangeLog 2012-05-31 16:36:29 UTC (rev 119113) @@ -1,3 +1,35 @@ +2012-05-31 commit-qu...@webkit.org commit-qu...@webkit.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc Can whoever made this change fix the change log? Thanks ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-changes] [119113] trunk/Source/WebKit/gtk
+mrobinson Looks like the odd ChangeLog was in a patch uploaded by mrobinson: https://bugs.webkit.org/attachment.cgi?id=143171action=review Adam On Thu, May 31, 2012 at 1:43 PM, Dan Bernstein m...@apple.com wrote: On May 31, 2012, at 9:36 AM, commit-qu...@webkit.org wrote: Revision119113Authorcommit-queue@webkit.orgDate2012-05-31 09:36:29 -0700 (Thu, 31 May 2012) Modified: trunk/Source/WebKit/gtk/ChangeLog (119112 = 119113) --- trunk/Source/WebKit/gtk/ChangeLog 2012-05-31 16:32:33 UTC (rev 119112) +++ trunk/Source/WebKit/gtk/ChangeLog 2012-05-31 16:36:29 UTC (rev 119113) @@ -1,3 +1,35 @@ +2012-05-31 commit-qu...@webkit.org commit-qu...@webkit.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc Can whoever made this change fix the change log? Thanks ___ 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] We should rename layoutTestController to testController
2012/5/31 Ojan Vafai o...@chromium.org: testController seems fine to me. I agree it's an improvement. On the other hand there are other tasks that have more benefit in terms of code maintenance for people wanting to spend time working in this area. A couple ideas: Move more APIs that only depend WebCore code to internals. Reduces code duplication and complexity. Just a heads-up: there is a meta bug tracking this at https://bugs.webkit.org/show_bug.cgi?id=87284 . A few folks have been going through the list created during the hackathon (https://trac.webkit.org/wiki/Internals_Hackathon) and picking a method to port every now and then. We were following the if-it-depends-only-on-WebCore-code-it-should-be-moved idea quite strictly, but now it seems we are facing a trade-off about internals x private WebKit APIs/SPIs from a few ports being tested. In other words, a few methods from layoutTestController are also testing code (private?) from WebKit and moving them to internals can leave these untested... For Qt I'm removing private methods that were only used by DRT or WTR, but I can't make this decision for other ports. Anyway, if you know something that can be moved for sure, just open a bug blocking b87284 and I'm quite sure there will be people happy to work on it. Cheers, jesus Work on exposing things like eventSender through an NPAPI plugin. That way it can be shared across browser vendors and could be used by the W3C test harness as well. This would be for APIs that we want for testing but don't make sense to expose to the web. Ojan On Thu, May 31, 2012 at 11:56 AM, Darin Adler da...@apple.com wrote: I am thinking we should rename layoutTestController to testController. Or if you don’t like that name, maybe testHarness or some even better name. The old name is too long and the word “layout” is so strange. We could expose the object under the new name and the old one, and then over time convert all the tests to the new name, then get rid of the old one. What do you all think? -- 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] We should rename layoutTestController to testController
2012/5/31 Dan Bernstein m...@apple.com: On May 31, 2012, at 12:11 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, May 31, 2012 at 11:56 AM, Darin Adler da...@apple.com wrote: I am thinking we should rename layoutTestController to testController. Or if you don’t like that name, maybe testHarness or some even better name. testController seems like a misnomer since it doesn't really control the test itself. I would prefer testRunnerController or simply testRunner since it's quite self-evident that methods on testRunner would act on the test runner itself. I like the name testRunner. I like it too. We could expose the object under the new name and the old one, and then over time convert all the tests to the new name, then get rid of the old one. That sounds like a good idea. Can we also rename LayoutTests to RegressionTests? I know Dave (Hyatt) suggested to cleanup the render tree dump format to get rid of all hacks and tweaks we've added over years, and my preference is to combine all these efforts and put new types of tests in trunk/RegressionTests. We'll move tests from LayoutTests to RegressionTests as we convert. We'll get rid of LayoutTests directory once all tests have been converted to use testRunner and new render tree dump format. - Ryosuke ___ 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] We should rename layoutTestController to testController
Darin, sorry for derailing this thread. I suppose I should have changed the subject. :) On Thu, May 31, 2012 at 1:51 PM, Jesus Sanchez-Palencia je...@webkit.orgwrote: Just a heads-up: there is a meta bug tracking this at https://bugs.webkit.org/show_bug.cgi?id=87284 . A few folks have been going through the list created during the hackathon (https://trac.webkit.org/wiki/Internals_Hackathon) and picking a method to port every now and then. Awesome! We were following the if-it-depends-only-on-WebCore-code-it-should-be-moved idea quite strictly, but now it seems we are facing a trade-off about internals x private WebKit APIs/SPIs from a few ports being tested. In other words, a few methods from layoutTestController are also testing code (private?) from WebKit and moving them to internals can leave these untested... For Qt I'm removing private methods that were only used by DRT or WTR, but I can't make this decision for other ports. If any of these involve the Chromium port, I'm sure we'd be happy to accommodate whatever is needed to move the API to internals. Feel free to CC me on bugs where that's the case. Anyway, if you know something that can be moved for sure, just open a bug blocking b87284 and I'm quite sure there will be people happy to work on it. Cheers, jesus Work on exposing things like eventSender through an NPAPI plugin. That way it can be shared across browser vendors and could be used by the W3C test harness as well. This would be for APIs that we want for testing but don't make sense to expose to the web. Ojan On Thu, May 31, 2012 at 11:56 AM, Darin Adler da...@apple.com wrote: I am thinking we should rename layoutTestController to testController. Or if you don’t like that name, maybe testHarness or some even better name. The old name is too long and the word “layout” is so strange. We could expose the object under the new name and the old one, and then over time convert all the tests to the new name, then get rid of the old one. What do you all think? -- 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] We should rename layoutTestController to testController
On May 31, 2012, at 3:11 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, May 31, 2012 at 11:56 AM, Darin Adler da...@apple.com wrote: I am thinking we should rename layoutTestController to testController. Or if you don’t like that name, maybe testHarness or some even better name. testController seems like a misnomer since it doesn't really control the test itself. I would prefer testRunnerController or simply testRunner since it's quite self-evident that methods on testRunner would act on the test runner itself. We could expose the object under the new name and the old one, and then over time convert all the tests to the new name, then get rid of the old one. That sounds like a good idea. Can we also rename LayoutTests to RegressionTests? I know Dave (Hyatt) suggested to cleanup the render tree dump format to get rid of all hacks and tweaks we've added over years, and my preference is to combine all these efforts and put new types of tests in trunk/RegressionTests. We'll move tests from LayoutTests to RegressionTests as we convert. We'll get rid of LayoutTests directory once all tests have been converted to use testRunner and new render tree dump format. I don't think renaming the directory should be tired to changing the output format. In particular, it would be confusing to have both RegressionTests and LayoutTests exist at the same time for an extended period. I don't think it has worked out very well to have both WebCore/platform/ and Platform/ exist at the same time, for instance. There are other ways to track an incremental conversion effort. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] We should rename layoutTestController to testController
On Thu, May 31, 2012 at 2:05 PM, Maciej Stachowiak m...@apple.com wrote: On May 31, 2012, at 3:11 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, May 31, 2012 at 11:56 AM, Darin Adler da...@apple.com wrote: I am thinking we should rename layoutTestController to testController. Or if you don’t like that name, maybe testHarness or some even better name. testController seems like a misnomer since it doesn't really control the test itself. I would prefer testRunnerController or simply testRunner since it's quite self-evident that methods on testRunner would act on the test runner itself. We could expose the object under the new name and the old one, and then over time convert all the tests to the new name, then get rid of the old one. That sounds like a good idea. Can we also rename LayoutTests to RegressionTests? I know Dave (Hyatt) suggested to cleanup the render tree dump format to get rid of all hacks and tweaks we've added over years, and my preference is to combine all these efforts and put new types of tests in trunk/RegressionTests. We'll move tests from LayoutTests to RegressionTests as we convert. We'll get rid of LayoutTests directory once all tests have been converted to use testRunner and new render tree dump format. I don't think renaming the directory should be tired to changing the output format. In particular, it would be confusing to have both RegressionTests and LayoutTests exist at the same time for an extended period. I don't think it has worked out very well to have both WebCore/platform/ and Platform/ exist at the same time, for instance. There are other ways to track an incremental conversion effort. I don't expect it to exist for an extended period of time since it's just a matter of rebaselining results. Given a good tool (which we're going to write), I'd expect it to be done in a matter of weeks if not in days. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] testharness Wiki page added
On May 31, 2012, at 2:18 PM, Jacob Goldstein jac...@adobe.com wrote: I added the following Wiki page to provide some information on testharness.js (the JavaScript framework from W3C recently landed in WebKit): http://trac.webkit.org/wiki/Writing%20testharness%20Tests I also updated the text under Writing JavaScript-based DOM only test cases on this page http://trac.webkit.org/wiki/Writing%20Layout%20Tests%20for%20DumpRenderTree. Note that I am recommending the use of testharness.js / testharnessreport.js over js-test-pre.js/js-test-post.js, when applicable, since tests written using testharness can be copied to the W3C test repository with only minor changes. Please review and send me any feedback on these pages. I am considering adding a detailed example to the testharness wiki page to demonstrate how the API should be used. In my experience, the W3C's DOM test harness results in tests that are more verbose, are less readable, and which have less readable output, as compared to js-test-pre.hs. I wish we would improve the W3C's upstream test harness instead of degrading the quality of our own tests. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Moving methods from layoutTestController to window.internals (was We should rename layoutTestController to testController)
2012/5/31 Ojan Vafai o...@chromium.org: Darin, sorry for derailing this thread. I suppose I should have changed the subject. :) Fixed. :) On Thu, May 31, 2012 at 1:51 PM, Jesus Sanchez-Palencia je...@webkit.org wrote: We were following the if-it-depends-only-on-WebCore-code-it-should-be-moved idea quite strictly, but now it seems we are facing a trade-off about internals x private WebKit APIs/SPIs from a few ports being tested. In other words, a few methods from layoutTestController are also testing code (private?) from WebKit and moving them to internals can leave these untested... For Qt I'm removing private methods that were only used by DRT or WTR, but I can't make this decision for other ports. If any of these involve the Chromium port, I'm sure we'd be happy to accommodate whatever is needed to move the API to internals. Feel free to CC me on bugs where that's the case. Good to know, thanks! It would be nice if people from other ports could also raise their hands as well so we don't bother the wrong ones. By the way, following the meta bug I could see that there are a few patches needing some care from reviewers, guys! Cheers, jesus Anyway, if you know something that can be moved for sure, just open a bug blocking b87284 and I'm quite sure there will be people happy to work on it. Cheers, jesus Work on exposing things like eventSender through an NPAPI plugin. That way it can be shared across browser vendors and could be used by the W3C test harness as well. This would be for APIs that we want for testing but don't make sense to expose to the web. Ojan On Thu, May 31, 2012 at 11:56 AM, Darin Adler da...@apple.com wrote: I am thinking we should rename layoutTestController to testController. Or if you don’t like that name, maybe testHarness or some even better name. The old name is too long and the word “layout” is so strange. We could expose the object under the new name and the old one, and then over time convert all the tests to the new name, then get rid of the old one. What do you all think? -- 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] testharness Wiki page added
I haven't found that to be the case for the tests I have written for each suite, the output from testharness can be as simple as PASS or FAIL, or include additional debug information defined by the test author. That being said, my experience is likely more limited than yours. Peter Linss, who wrote and maintains the W3C testharness, would likely be open to suggestions for improvement if there is anything specific that we want to change. From: Maciej Stachowiak m...@apple.commailto:m...@apple.com To: Jacob Goldstein jac...@adobe.commailto:jac...@adobe.com Cc: WebKit Development webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] testharness Wiki page added On May 31, 2012, at 2:18 PM, Jacob Goldstein jac...@adobe.commailto:jac...@adobe.com wrote: I added the following Wiki page to provide some information on testharness.js (the JavaScript framework from W3C recently landed in WebKit): http://trac.webkit.org/wiki/Writing%20testharness%20Tests I also updated the text under Writing JavaScript-based DOM only test cases on this page http://trac.webkit.org/wiki/Writing%20Layout%20Tests%20for%20DumpRenderTree. Note that I am recommending the use of testharness.js / testharnessreport.js over js-test-pre.js/js-test-post.js, when applicable, since tests written using testharness can be copied to the W3C test repository with only minor changes. Please review and send me any feedback on these pages. I am considering adding a detailed example to the testharness wiki page to demonstrate how the API should be used. In my experience, the W3C's DOM test harness results in tests that are more verbose, are less readable, and which have less readable output, as compared to js-test-pre.hs. I wish we would improve the W3C's upstream test harness instead of degrading the quality of our own tests. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] testharness Wiki page added
Actually, I misspoke, it's not Peter Linss who maintains testharness, it's James Graham. From: Jacob Goldstein jac...@adobe.commailto:jac...@adobe.com To: Maciej Stachowiak m...@apple.commailto:m...@apple.com Cc: WebKit Development webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] testharness Wiki page added I haven't found that to be the case for the tests I have written for each suite, the output from testharness can be as simple as PASS or FAIL, or include additional debug information defined by the test author. That being said, my experience is likely more limited than yours. Peter Linss, who wrote and maintains the W3C testharness, would likely be open to suggestions for improvement if there is anything specific that we want to change. From: Maciej Stachowiak m...@apple.commailto:m...@apple.com To: Jacob Goldstein jac...@adobe.commailto:jac...@adobe.com Cc: WebKit Development webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] testharness Wiki page added On May 31, 2012, at 2:18 PM, Jacob Goldstein jac...@adobe.commailto:jac...@adobe.com wrote: I added the following Wiki page to provide some information on testharness.js (the JavaScript framework from W3C recently landed in WebKit): http://trac.webkit.org/wiki/Writing%20testharness%20Tests I also updated the text under Writing JavaScript-based DOM only test cases on this page http://trac.webkit.org/wiki/Writing%20Layout%20Tests%20for%20DumpRenderTree. Note that I am recommending the use of testharness.js / testharnessreport.js over js-test-pre.js/js-test-post.js, when applicable, since tests written using testharness can be copied to the W3C test repository with only minor changes. Please review and send me any feedback on these pages. I am considering adding a detailed example to the testharness wiki page to demonstrate how the API should be used. In my experience, the W3C's DOM test harness results in tests that are more verbose, are less readable, and which have less readable output, as compared to js-test-pre.hs. I wish we would improve the W3C's upstream test harness instead of degrading the quality of our own tests. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] testharness Wiki page added
On Thu, May 31, 2012 at 11:18 AM, Jacob Goldstein jac...@adobe.commailto:jac...@adobe.com wrote: I added the following Wiki page to provide some information on testharness.js (the JavaScript framework from W3C recently landed in WebKit): http://trac.webkit.org/wiki/Writing%20testharness%20Tests I also updated the text under Writing JavaScript-based DOM only test cases on this page http://trac.webkit.org/wiki/Writing%20Layout%20Tests%20for%20DumpRenderTree. Note that I am recommending the use of testharness.js / testharnessreport.js over js-test-pre.js/js-test-post.js, when applicable, since tests written using testharness can be copied to the W3C test repository with only minor changes. Note that this isn't true once we start using layoutTestController in the test. Tests that we currently use LTC such as to invoke mouse events, keyboard events, etc... are currently manual tests in W3C test suites. They use meta elements to tag manual tests but the actual instruction is just regular English sentences. It would be good to codify this information so that we can automate some of W3C manual tests at least in WebKit. Would the W3C WebDriver specification you mentioned in another thread replace the need to use LTC for these types of events? - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Settings::devicePixelRatio and Settings::defaultDeviceScaleFactor
Is there any difference between Settings::devicePixelRatio [1] and Settings::defaultDeviceScaleFactor [2] ? They appear to be used by disjoint sets of ports. Shall we delete one in favor of the other? Adam [1] http://trac.webkit.org/browser/trunk/Source/WebCore/page/Settings.h#L478 [2] http://trac.webkit.org/browser/trunk/Source/WebCore/page/Settings.h#L106 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Settings::devicePixelRatio and Settings::defaultDeviceScaleFactor
I don' t think devicePixelRatio() belongs in settings. It should be either be obtained from the platform code in WebCore/WebKit, or pushed in via API. Simon On May 31, 2012, at 3:48 PM, Adam Barth wrote: Is there any difference between Settings::devicePixelRatio [1] and Settings::defaultDeviceScaleFactor [2] ? They appear to be used by disjoint sets of ports. Shall we delete one in favor of the other? Adam [1] http://trac.webkit.org/browser/trunk/Source/WebCore/page/Settings.h#L478 [2] http://trac.webkit.org/browser/trunk/Source/WebCore/page/Settings.h#L106 ___ 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] Settings::devicePixelRatio and Settings::defaultDeviceScaleFactor
(top-posting to fit in) Doesn't the same argument apply to *deviceScaleFactor? That doesn't make sense as a Setting either. Pushing one or both out of settings doesn't answer the question of whether they are redundant. My gut feeling is that they are and we should fold them together. Alternately, delete defaultDeviceScaleFactor completely. - James On Thu, May 31, 2012 at 3:50 PM, Simon Fraser simon.fra...@apple.comwrote: I don' t think devicePixelRatio() belongs in settings. It should be either be obtained from the platform code in WebCore/WebKit, or pushed in via API. Simon On May 31, 2012, at 3:48 PM, Adam Barth wrote: Is there any difference between Settings::devicePixelRatio [1] and Settings::defaultDeviceScaleFactor [2] ? They appear to be used by disjoint sets of ports. Shall we delete one in favor of the other? Adam [1] http://trac.webkit.org/browser/trunk/Source/WebCore/page/Settings.h#L478 [2] http://trac.webkit.org/browser/trunk/Source/WebCore/page/Settings.h#L106 ___ 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] Settings::devicePixelRatio and Settings::defaultDeviceScaleFactor
I agree, having this in Settings seems to imply that the browser's physical device remains the same for its entire lifetime which is not true. - Dana On Thu, May 31, 2012 at 6:52 PM, James Robinson jam...@google.com wrote: (top-posting to fit in) Doesn't the same argument apply to *deviceScaleFactor? That doesn't make sense as a Setting either. Pushing one or both out of settings doesn't answer the question of whether they are redundant. My gut feeling is that they are and we should fold them together. Alternately, delete defaultDeviceScaleFactor completely. - James On Thu, May 31, 2012 at 3:50 PM, Simon Fraser simon.fra...@apple.comwrote: I don' t think devicePixelRatio() belongs in settings. It should be either be obtained from the platform code in WebCore/WebKit, or pushed in via API. Simon On May 31, 2012, at 3:48 PM, Adam Barth wrote: Is there any difference between Settings::devicePixelRatio [1] and Settings::defaultDeviceScaleFactor [2] ? They appear to be used by disjoint sets of ports. Shall we delete one in favor of the other? Adam [1] http://trac.webkit.org/browser/trunk/Source/WebCore/page/Settings.h#L478 [2] http://trac.webkit.org/browser/trunk/Source/WebCore/page/Settings.h#L106 ___ 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] Settings::devicePixelRatio and Settings::defaultDeviceScaleFactor
I've been working on patches that remove target-densitydpi and/or defaultDeviceScaleFactor, which is what caused me to ask this question. I suspect they can both be removed, but I might need some help from folks with development environments for the various ports that use one or the other. Adam On Thu, May 31, 2012 at 3:52 PM, James Robinson jam...@google.com wrote: (top-posting to fit in) Doesn't the same argument apply to *deviceScaleFactor? That doesn't make sense as a Setting either. Pushing one or both out of settings doesn't answer the question of whether they are redundant. My gut feeling is that they are and we should fold them together. Alternately, delete defaultDeviceScaleFactor completely. - James On Thu, May 31, 2012 at 3:50 PM, Simon Fraser simon.fra...@apple.com wrote: I don' t think devicePixelRatio() belongs in settings. It should be either be obtained from the platform code in WebCore/WebKit, or pushed in via API. Simon On May 31, 2012, at 3:48 PM, Adam Barth wrote: Is there any difference between Settings::devicePixelRatio [1] and Settings::defaultDeviceScaleFactor [2] ? They appear to be used by disjoint sets of ports. Shall we delete one in favor of the other? Adam [1] http://trac.webkit.org/browser/trunk/Source/WebCore/page/Settings.h#L478 [2] http://trac.webkit.org/browser/trunk/Source/WebCore/page/Settings.h#L106 ___ 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] [webkit-changes] [119113] trunk/Source/WebKit/gtk
On Thu, May 31, 2012 at 1:46 PM, Adam Barth aba...@webkit.org wrote: +mrobinson Looks like the odd ChangeLog was in a patch uploaded by mrobinson: https://bugs.webkit.org/attachment.cgi?id=143171action=review Apologies. I'm unsure how this patch became corrupted. I've fixed the ChangeLog. --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] testharness Wiki page added
On Thu, May 31, 2012 at 3:33 PM, Jacob Goldstein jac...@adobe.com wrote: On Thu, May 31, 2012 at 11:18 AM, Jacob Goldstein jac...@adobe.comwrote: I added the following Wiki page to provide some information on testharness.js (the JavaScript framework from W3C recently landed in WebKit): http://trac.webkit.org/wiki/Writing%20testharness%20Tests I also updated the text under Writing JavaScript-based DOM only test cases on this page http://trac.webkit.org/wiki/Writing%20Layout%20Tests%20for%20DumpRenderTree. Note that I am recommending the use of testharness.js / testharnessreport.js *over* js-test-pre.js/js-test-post.js, when applicable, since tests written using testharness can be copied to the W3C test repository with only minor changes. Note that this isn't true once we start using layoutTestController in the test. Tests that we currently use LTC such as to invoke mouse events, keyboard events, etc... are currently manual tests in W3C test suites. They use meta elements to tag manual tests but the actual instruction is just regular English sentences. It would be good to codify this information so that we can automate some of W3C manual tests at least in WebKit. Would the W3C WebDriver specification you mentioned in another thread replace the need to use LTC for these types of events? I've discussed briefly with James Graham from Opera but apparently WebDriver is tended to be an external API, meaning that there will be a test driver that uses this API in addition to the test itself. There appears to be some some effort to add a JS binding but it's still not visible within the test. But we might be able to find a middle ground here where we codify the WebDriver instructions in some sort of manifest/configuration file in addition to the test, and then we'll manipulate that to work with our test harness at the importation time or when we run tests. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] testharness Wiki page added
On May 31, 2012, at 7:55 PM, Maciej Stachowiak wrote: On May 31, 2012, at 5:51 PM, Jacob Goldstein jac...@adobe.com wrote: I haven't found that to be the case for the tests I have written for each suite, the output from testharness can be as simple as PASS or FAIL, or include additional debug information defined by the test author. That being said, my experience is likely more limited than yours. Peter Linss, who wrote and maintains the W3C testharness, would likely be open to suggestions for improvement if there is anything specific that we want to change. The source is more verbose. The output is uglier and less clear, at least by default. PASS and FAIL is not as good as what our test driver does by default, because you can't as easily tell what passed or failed or why. Our own harness tells you the expression the test evaluated that failed, and what the expected result was, so it's much quicker to debug a failure. I have given my feedback to James Graham before, including showing him how our test harness works. At the time, he was not open to making changes, in part because of details of Opera's internal testing setup and in part because eval is evil. I really would rather not reduce all our DOM tests to the Opera-driven level of source legibility and output quality. I think it is time not to discuss it privately anymore. This is the test suite that is/will be used by the CSS WG. Therefore, if there are reasonable suggestions for improvement, we should discuss it on public mailing lists. webkit-dev is a great start, but since it is used by CSS WG and since all contributors, not just opera contributors, need to use it on the CSS WG test suite, it should be discussed on the CSS WG side. The responsible mailing list should be public-css-testsuite. Let me give you an example. This zip file contains an actual w3c test case, and a webkit-style conversion of the same test: test-example.zip I have deliberately introduced the same failure into both. Which one do you think would be easier to debug? I agree, the output of the WebKit harness seems to be more useful and better for debugging. But I used to use the WebKit testing harness a lot. So my impressions are not independent. Greetings, Dirk Regards, Maciej ___ 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
