Re: [webkit-dev] Unprefixing Blob.webkitSlice() ?
On Mon, Jun 11, 2012 at 3:34 PM, Darin Fisher wrote: > Happy to see us support unprefixed too. With other vendors on board, it > seems like a straightforward addition to the platform. > > I'm not sure if you are proposing to also remove the prefixed form. I'm > not sure what it would take to remove the prefixed version. We'd need some > way to know when it is safe to remove it. We could surely instrument the > code to measure its use relative to the unprefixed form once it is widely > deployed. > We've been shipping the prefixed version for a year now (in Chrome 11-19 and in Safari 5), so I propose keeping the prefixed version too for now, but to start showing a deprecation message to encourage migration. -Darin > > > On Sun, Jun 10, 2012 at 11:17 PM, Kinuko Yasuda wrote: > >> Hi WebKit folks, >> >> We've been vendor-prefixing Blob.slice() since we changed the semantics >> of slice() to make it alike Array.slice, i.e. from "start, length" to >> "start, end" semantics in r83873 [1]. The non-prefixed version had only >> been shipped in Chrome and must have helped apps migrate into the new >> semantics. >> However Mozilla has now unprefixed it since Gecko/FireFox 13.0 [2], Opera >> said they are going to unprefix it with the new semantics [3] and IE >> compatibility test has a set of Blob.slice tests which require unprefixed >> slice [4]. >> >> Maybe it's becoming a good time to unprefix slice() again? >> https://bugs.webkit.org/show_bug.cgi?id=78111 >> >> [1] http://trac.webkit.org/changeset/83873 >> [2] >> https://developer.mozilla.org/en/DOM/Blob#Notes_on_the_slice()_implementations >> [3] https://bugs.webkit.org/show_bug.cgi?id=78111 >> [4] http://samples.msdn.microsoft.com/ietestcenter/#fileapi >> >> Kinuko >> >> >> ___ >> 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] Unprefixing Blob.webkitSlice() ?
Happy to see us support unprefixed too. With other vendors on board, it seems like a straightforward addition to the platform. I'm not sure if you are proposing to also remove the prefixed form. I'm not sure what it would take to remove the prefixed version. We'd need some way to know when it is safe to remove it. We could surely instrument the code to measure its use relative to the unprefixed form once it is widely deployed. -Darin On Sun, Jun 10, 2012 at 11:17 PM, Kinuko Yasuda wrote: > Hi WebKit folks, > > We've been vendor-prefixing Blob.slice() since we changed the semantics of > slice() to make it alike Array.slice, i.e. from "start, length" to "start, > end" semantics in r83873 [1]. The non-prefixed version had only been > shipped in Chrome and must have helped apps migrate into the new semantics. > However Mozilla has now unprefixed it since Gecko/FireFox 13.0 [2], Opera > said they are going to unprefix it with the new semantics [3] and IE > compatibility test has a set of Blob.slice tests which require unprefixed > slice [4]. > > Maybe it's becoming a good time to unprefix slice() again? > https://bugs.webkit.org/show_bug.cgi?id=78111 > > [1] http://trac.webkit.org/changeset/83873 > [2] > https://developer.mozilla.org/en/DOM/Blob#Notes_on_the_slice()_implementations > [3] https://bugs.webkit.org/show_bug.cgi?id=78111 > [4] http://samples.msdn.microsoft.com/ietestcenter/#fileapi > > Kinuko > > > ___ > 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] Unprefixing Blob.webkitSlice() ?
Hi WebKit folks, We've been vendor-prefixing Blob.slice() since we changed the semantics of slice() to make it alike Array.slice, i.e. from "start, length" to "start, end" semantics in r83873 [1]. The non-prefixed version had only been shipped in Chrome and must have helped apps migrate into the new semantics. However Mozilla has now unprefixed it since Gecko/FireFox 13.0 [2], Opera said they are going to unprefix it with the new semantics [3] and IE compatibility test has a set of Blob.slice tests which require unprefixed slice [4]. Maybe it's becoming a good time to unprefix slice() again? https://bugs.webkit.org/show_bug.cgi?id=78111 [1] http://trac.webkit.org/changeset/83873 [2] https://developer.mozilla.org/en/DOM/Blob#Notes_on_the_slice()_implementations [3] https://bugs.webkit.org/show_bug.cgi?id=78111 [4] http://samples.msdn.microsoft.com/ietestcenter/#fileapi Kinuko ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Running layout tests for the chromium port, using the multi-processing architecture and fully sandboxed
On Fri, Jun 8, 2012 at 12:51 PM, Jochen Eisinger wrote: > > > On Fri, Jun 8, 2012 at 9:41 PM, Ryosuke Niwa wrote: > >> On Fri, Jun 8, 2012 at 12:18 PM, Jochen Eisinger wrote: >> >>> I've implemented initial support for running layout tests using >>> chromium's content_shell instead of test_shell as the current DRT >>> implementation does. It's still a very experimental, but might already be >>> interesting for some of you to try. >>> >> >> This is great! Thanks a lot on working this. >> >> 1. Make sure your WebKit is at least at r119852 (see >>> http://trac.webkit.org/wiki/Chromium for prerequisites) >>> 2. Apply the attachment from >>> https://bugs.webkit.org/show_bug.cgi?id=87045 >>> 3. In Source/WebKit/chromium run gclient sync >>> 4. build webkit as usual >>> >>> E.g. for a debug build on Linux, this should give you >>> out/Debug/content_shell >>> >>> You can now run layout tests like this: >>> >>> new-run-webkit-tests --chromium --debug --driver-name=content_shell >>> --additional-drt-flag=--dump-render-tree LayoutTests/storage/indexeddb/* >>> >>> You'll notice that not all tests are passing yet, mainly because not all >>> (or actually, almost none of the) layoutTestController features are >>> implemented yet. >>> >> >> Where is layoutTestController implemented? We definitely need to move >> the implementation of layoutTestController, eventSender, etc... into WebKit >> repository because we often rename functions, etc... in WebKit. It's >> unacceptable to require having to modify Chromium code in order to do this >> refactoring in the future. >> > > It's currently here: > http://code.google.com/searchframe#OAMlx_jo-ck/src/content/shell/layout_test_controller.js&exact_package=chromium > > Per my other thread about sharing IDLs between DumpRenderTree and >> WebKitTestRunner, I would like to see us sharing IDL with WebKitTestRunner >> instead of adding yet another binding code. >> >> Another missing feature is producing pixel results. However, I'm >>> currently concentrating on text results, as I think the biggest benefit is >>> the ability to run storage tests on the real storage implementation. >>> >> >> That sounds great to me but we definitely need to support pixel results >> eventually. I'm more than happy to help you on that but that requires the >> codebase to be moved into WebKit repository. >> > > Here's the basic problem: content_shell depends on content, so moving this > on the webkit repository would mean that webkit depended on content. > > Another solution would be to formalize the test shell API our current > layout test controller in webkit uses (Tools/DumpRenderTree/chromium), and > add a method to chromium's webkit support library that returns a webview > that supports all the hooks required. The webview could then either be > implemented by test_shell or by content_shell > > ^^^ This second solution seems like it will work well. It will enable the guts of layoutTestController to remain in the WebKit repository. This is just a variation of exactly what we do today. You only need to move creation of WebView to Chromium so that we can eliminate WebViewHost.cpp (and other "simple" application shell bits). -Darin > best > -jochen > > ___ > 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] Using the WebExposed keyword for web-facing changes
Do you want WebExposed for a simple bug fix of an existing feature? Do you want it for bugs with no patches? On Sat, Jun 9, 2012 at 5:24 AM, Peter Beverloo wrote: Hi webkit-dev, *If you work on web-facing features, or run into another bug which does, please consider adding the **"**WebExposed**"** keyword to it.* Many of you will be familiar with my WebKit updates, which are now also being published on the WebKit blog. Writing these involves reading every commit that lands in WebKit's repository. Last year, May counted 2,126 revisions. This year there were 3,068. As a result of the steep increase in volume, it's becoming increasingly hard for all parties to keep up -- Web(Kit) developers, ports and all other interested parties. Not every one of them has time to read through all changes. In an effort to increase visibility of Web Platform facing changes, I'd like to introduce the "WebExposed" keyword. It is intended to be applied to any bug which introduces, modifies (including behavioral changes) or removes features important to Web developers, such as DOM properties and methods, JavaScript features and CSS properties and values. https://bugs.webkit.org/buglist.cgi?keywords=WebExposed Increased visibility of these changes has a number of advantages. Firstly, Web Developers will have more insight in what's happening in WebKit. The changes will be visible on the bug list itself, but also through the RSS feed Bugzilla will curate for it. Furthermore, it may be used as an overview for ports to keep track of the web-facing changes which happen during their release cycles, and it will also come in useful for evangelizing features, writing documentation and managing outreach. With work being done by many vendors in many areas of WebCore, I'm hoping the keyword can become a valuable aid in this respect. If you work on web-facing features, or run into another bug which does, please consider adding the "WebExposed" keyword to it. This of course isn't mandatory, but it will help others who are interested in keeping track. Thanks, Peter ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- TAMURA Kent Software Engineer, Google ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] GTK+ port's help needed to get rid of FAIL test expectation
I think it would suffice to replace all the FAIL occurrences with TEXT, except for the failing reftests - those should have FAIL turned into IMAGE. Gtk bots don't run pixel tests yet so any other IMAGE failures could perhaps be addressed at later time. I'd like some approval on this from the senior maintainers, after that FAIL should disappear from Gtk's TestExpectations pretty soon. Regards, Zan On Sat, Jun 9, 2012 at 9:35 PM, Ryosuke Niwa wrote: > On Sat, Jun 9, 2012 at 12:27 PM, Ojan Vafai wrote: > >> Can you just expand out FAIL to it's equivalent longform? FAIL == TEXT >> IMAGE IMAGE+TEXT. I don't see a need to block the infrastructure change on >> this as the semantics are exactly the same. You can just find/replace every >> instance of FAIL. >> > > I could. But it appears that most entries in GTK+'s test expectations file > has FAIL expectation so I'd rather make sure it's not intentional, etc... > > - 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] can we stop using Skipped files?
> Untested code is inherently harder to maintain in my experience. Most of > the time, committing untested code is just implanting technical debt that > someone will have to pay later. > > I think the above, by its own, summarizes what people advocating in favor of tests (for any area of the project, and tooling is not an exception) are arguing for. -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Plug Ins dont work when rebuilding WebKit
Hi There I know this has been discussed before, but the solution doesn't work for me I am making a tiny behavioural change to WebCore, then rebuilding WebKit to use in a specialist application. When I am done building I move the frameworks into the pre-built WebKit nightly build application. This works great, and the WebCore now does what I want. However the QuickTime Plug-in no longer works, where it did before I switched out the frameworks. I know that in theory I can just copy the "WebKitPluginHost" and "WebKitPluginAgent" from the original nightly build into my own WebKit folder, but that does NOT work for me. Its the same if I rework the nightly build app, or use run-safari script. No Plug ins. Could anyone advise how to troubleshoot this ? Whilst I am on the topic, if I am only making a change to WebCore, how could I just replace the WebCore framework into the Nightly build app instead of all the parts. When I try that, the app doesn't really work right, so I am guessing there are some more complex dependancies between builds. Thanks for any tips. Mark. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] can we stop using Skipped files?
On Sun, Jun 10, 2012 at 4:54 AM, Balazs Kelemen wrote: > > So the unit tests are superfluous. In particular, if I had to pick >> between only having unit tests or only having regression tests, I might >> pick unit tests. But if I already have regression tests then I'm unlikely >> to want to incur technical debt to build unit tests, particularly since >> unit tests requiring changing the infrastructure to make the code more >> testable, which then leads to the problems listed above. >> > > There are many code paths are used rarely. In practice, we were having > regressions frequently when people modified the code. Since the codebase > has been unittested, the rate of regressions has gone down considerably. > The time you spend dealing with tests is considerably less than the time > you spend rolling patches in an out as you encounter different edge cases > that different configurations/flags hit. > > > > A quick note to unittests. I think it's easy to define a hard limit for > unittests, which is that: if I want to add a feature, or some customizing > option for a particular port, it should be less effort to write the > unittest than to write the actual code. I heard from my colleges a few > times that it's not always the case with nrwt. I can imagine that it's not > trivial to setup the unittest system for a module that has not been > unittested so far but I think it should rather be the job of those who are > actively working on the test harness, not of those who just need some work > to be done for their port. > While this is a nice ideal to strive for, I don't think this ever plays out for testing on any project, e.g. it is very frequently harder to write tests for my WebCore changes than to make the change itself. Certainly anything we can do to make testing easier is better, but I don't see NRWT as more difficult to test than any other code in the WebKit project. WebKit has a policy of every change requiring tests. I don't see why tooling should be any different. It's unfortunate that NRWT started with 0 tests, so there are still (very few now!) parts that aren't tested. It's hard to test those parts if that's what your modifying. However, it's *especially* for the cases of port-specific code that need testing. Those are exactly the codepaths that break from lack of testing. Untested code is inherently harder to maintain in my experience. Most of the time, committing untested code is just implanting technical debt that someone will have to pay later. There's noone whose fulltime job is it to maintain WebKit tooling. It's a shared effort supported by everyone in the project. It's long been a part of WebKit culture as long as I've been involved in the project that sometimes you get stuck reworking code you didn't write in order to make your change because your change just barely pushes the existing messy code over the edge of too messy. It's true that it makes your simple change much harder, but it's better for the project overall, even if occasionally a patch doesn't get checked in because the associated work was more than the contributor was willing to do. Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] can we stop using Skipped files?
On Sun, Jun 10, 2012 at 4:54 AM, Balazs Kelemen wrote: > So the unit tests are superfluous. In particular, if I had to pick >> between only having unit tests or only having regression tests, I might >> pick unit tests. But if I already have regression tests then I'm unlikely >> to want to incur technical debt to build unit tests, particularly since >> unit tests requiring changing the infrastructure to make the code more >> testable, which then leads to the problems listed above. >> > > There are many code paths are used rarely. In practice, we were having > regressions frequently when people modified the code. Since the codebase > has been unittested, the rate of regressions has gone down considerably. > The time you spend dealing with tests is considerably less than the time > you spend rolling patches in an out as you encounter different edge cases > that different configurations/flags hit. > > A quick note to unittests. I think it's easy to define a hard limit for > unittests, which is that: if I want to add a feature, or some customizing > option for a particular port, it should be less effort to write the > unittest than to write the actual code. I heard from my colleges a few > times that it's not always the case with nrwt. I can imagine that it's not > trivial to setup the unittest system for a module that has not been > unittested so far but I think it should rather be the job of those who are > actively working on the test harness, not of those who just need some work > to be done for their port. > My experience with code in general (and Python in particular) is that code that isn't tested is broken. It's certainly true that several important parts of NRWT weren't designed with testing in mind, but that's something we should fix rather than piling on untested features. That said, I'm not actively working on NRWT much these days, and I'm happy to defer to the folks who are as to what they think is best for the long-term health of this code. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] can we stop using Skipped files?
So the unit tests are superfluous. In particular, if I had to pick between only having unit tests or only having regression tests, I might pick unit tests. But if I already have regression tests then I'm unlikely to want to incur technical debt to build unit tests, particularly since unit tests requiring changing the infrastructure to make the code more testable, which then leads to the problems listed above. There are many code paths are used rarely. In practice, we were having regressions frequently when people modified the code. Since the codebase has been unittested, the rate of regressions has gone down considerably. The time you spend dealing with tests is considerably less than the time you spend rolling patches in an out as you encounter different edge cases that different configurations/flags hit. A quick note to unittests. I think it's easy to define a hard limit for unittests, which is that: if I want to add a feature, or some customizing option for a particular port, it should be less effort to write the unittest than to write the actual code. I heard from my colleges a few times that it's not always the case with nrwt. I can imagine that it's not trivial to setup the unittest system for a module that has not been unittested so far but I think it should rather be the job of those who are actively working on the test harness, not of those who just need some work to be done for their port. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
