Re: [webkit-dev] Best practices for landing new/changed layout test expectations?
The steps described here differ from what I've been doing. In the interest of closure and port happiness, I've updated the wiki to reflect what is being proposed: https://trac.webkit.org/wiki/CreatingLayoutTests Please feel free to update it further. Philip On Tue, Feb 26, 2013 at 2:34 PM, Dirk Pranke dpra...@chromium.org wrote: On Tue, Feb 26, 2013 at 1:03 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Feb 26, 2013 at 12:47 PM, Dirk Pranke dpra...@chromium.org wrote: On Tue, Feb 26, 2013 at 2:11 AM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Feb 26, 2013 at 1:55 AM, Tom Hudson tomhud...@google.com wrote: On Mon, Feb 25, 2013 at 10:34 PM, Ryosuke Niwa rn...@webkit.org wrote: It should be fairly straight forward to create a tool that analyzes files changed in each commit and deduce which tests' expected results have been changed. The tool can then fetch results from each port' bot for those tests and automatically land them. It can then comment on the bug automatically about these rebaseline commits. There is no need to add remove entries from TestExpectation files. Wait, what? For some reason neither I nor the mailing list archives got your initial message, nor Silvia or Tom's responses, nor your responses (at least as of the time of me writing this), so I feel like I've missed a radical shift in this thread, and maybe I missed some of the context. https://lists.webkit.org/pipermail/webkit-dev/2013-February/023967.html This link doesn't point to any of those messages, but perhaps it's not that important. You're proposing that we automatically land updated baselines without review and then somehow update bugs, have people go back and look at the updated bugs to see if the baseline changes represent actual regressions or just expected changes? Right. Given that the commit already contains information as to which tests have been rebaselined, a script should be able to fetch new baselines for those affected tests on each platform and land them or upload as patches as needed. It's possible that we could fetch and cluster new baselines based on what changed in the initial commit. I would be concerned that there could be a fair amount of noise in either direction (tests that changed on the initial platform didn't on others, and others did), and you'd also have to figure out how to cluster changes since most builds on the bots contain multiple changes. But, you could probably use some of garden-o-matic's results to help here. That said, I'm not sure this workflow would actually improve things much over garden-o-matic. I am quite a bit more reluctant to automatically land any such changes; it seems like it would be hard if not impossible to tell (programmatically) whether a baseline changed as expected or if it represented a regression. If we were to work on new tooling, I would be much more in favor of pushing this up to an EWS-time step like Ossy suggests. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Can the Windows WebKit nightly build be removed?
http://nightly.webkit.org The Windows build is currently over 13,158 revisions behind. I recently received a Chromium bug that are actually a WebKit bug because the user was using the Windows nightly build to confirm. Philip ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New WebKit reviewer: Stephen Chenney
This is fantastic. Congratulations Stephen! On Wed, Feb 20, 2013 at 2:34 PM, Dirk Schulze k...@webkit.org wrote: Hi WebKit folks, It is a pleasure to announce that Stephen Chenney schen...@chromium.org is a WebKit Reviewer now. Stephen did and does an awesome job on various SVG, Font and Skia related topics. He fixed at least a dozen of urgent security bugs and has a great understanding of the WebCore code base. Please join me in congratulating Stephen for his new status! Greetings, Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Getting involved
One alternative to mass-reformatting is to improve the style checker. There are many cases not covered by it today: http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/style/checkers/cpp.py On Mon, Feb 18, 2013 at 3:30 PM, Simon Fraser simon.fra...@apple.comwrote: On Feb 18, 2013, at 2:45 PM, Jason Anderssen janders...@exactal.com wrote: Hi all, With a background in development (both windows and MAC) I was wanting to get involved in an open source project that I believe is going to make the world a greater place. So I have decided to get involved with the WebKit project. I would like to start of by performing the boring work of reformatting code to suite the guidelines as stipulated on the webkit.org website (and double check that they are still up to date), and would like recommendations to which parts of the project could do with the re-formatting first up. ( I feel this will get me to know the framework, and structure of the code base well, before I can start inputting my coding and help. ) Any feedback to where to start would be very much appreciated We actually shy away from mass code reformatting. It obscures useful revision history. It's fine to reformat code for code you're actually changing, but reformatting for the sake of reformatting isn't useful, and may be harmful. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Testing feature suggestion: animation/interaction pixel-results on the fly
I'm not sure if this is generally known: we use [svg document].setCurrentTime(time) in the svg/animations tests for both script and pixel tests. The SVG animation test harness leaves a lot to be desired, but it may be a good place to start for a more general DRT approach: http://trac.webkit.org/browser/trunk/LayoutTests/svg/animations/script-tests/animate-css-xml-attributeType.js#L62 Philip On Fri, Feb 8, 2013 at 4:26 PM, Gregg Tavares g...@google.com wrote: On Fri, Feb 8, 2013 at 4:16 PM, Benjamin Poulain benja...@webkit.orgwrote: On Fri, Feb 8, 2013 at 4:12 PM, Gregg Tavares g...@google.com wrote: Can you expose a time or setTime function in DRT and some option that says let JS control the clock? Unfortunately, that only works in the simple cases. We could cheat the WebCore clock, but that would ultimately be wrong for animations running in threads or driven outside WebCore. The point was you need to be able to control all the clocks if you want repeatable results. If you're saying some clocks can't be controlled that sounds like something needs to be refactored so it's testable. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Do any ports still disable SVG?
We could reduce a bit of maintenance cost by removing all the defines. I ran some numbers and I'm not sure we are there yet in terms of lost productivity, even on the Chromium side. SVG adds around 20% to debug compile times: Linux, Z620, no goma, clean build, ninja, Debug DumpRenderTree, without SVG: 4m05s Linux, Z620, no goma, clean build, ninja, Debug DumpRenderTree, with SVG: 4m52s Linux, Z620, no goma, clean build, ninja, Release DumpRenderTree, without SVG: 3m58s Linux, Z620, no goma, clean build, ninja, Release DumpRenderTree, with SVG: 4m36s For Chromium developers not working on WebKit it is probably best to continue building without SVG, even though I must warn you that you'll miss out on the some sweet graphics. Philip On Fri, Jan 25, 2013 at 12:19 PM, Elliott Sprehn espr...@chromium.orgwrote: Perhaps the time to remove ENABLE_SVG is in several years once many pages depend on it and disabling it results in a busted browser... On Fri, Jan 25, 2013 at 2:55 PM, Arunprasad Rajkumar ararunpra...@gmail.com wrote: Eric, Most of the resource constraint environments(embedded systems) still disables the SVG. If the define is removed code size of WebKit will be increased by atleast 3 to 4M. On 26 January 2013 01:01, webkit-dev-requ...@lists.webkit.org wrote: This question came up in:https://bugs.webkit.org/show_bug.cgi?id=92393 Do any ports still disable SVG? Should we be removing the ENABLE_SVG defines (and potentially unifying SVG and HTML style resolve more closely)? -- *Arunprasad Rajkumar* http://in.linkedin.com/in/ararunprasad ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] SVG video chat (3)
SVG WebKittens, The last video chat was well received and as a group we decided to do it again. If you'd like to join in please add your name, availability, and topics you'd like to discuss to the spreadsheet: https://docs.google.com/spreadsheet/ccc?key=0AorN2u5hCJiUdGc5cGJwZTBvVl9taVJZazYteHdnbkE Thanks, Philip ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.
Not that I admit to using printf debugging, but if I were to, hypothetically of course, I would find this patch helpful. On Mon, Jul 9, 2012 at 2:43 PM, Alexis Menard alexis.men...@openbossa.orgwrote: Hi, For those who secretly use printf debugging :). I know the recommended way is to use a debugger and it's not the point of this discussion. The other day I was working on the Mac port (with no real possibility to have a debug build) and I missed a lot a great feature we have in Qt : qDebug(). I find the usage of printf cumbersome (so is LOG and dataLog). QDebug prettify and ease printf based debug workflow. Even in WebKit using QDebug is pretty handy as very important core types of WebKit have a Qt representation (e.g. WTF::String can be converted to a QString). So you can do something like : String string(HELLO); qDebug()string and it just output HELLO for you. Much more efficient (to write ofc) than : fprintf(stderr, %s\n, string.utf8().data()); Still today a lot of WebKit core type have no counterpart in Qt (and will never have) so qDebug pretty much fail (worst case it shows a pointer address if possible). I'm also aware of NSLog but it unfortunately only work in objective c files. Then I thought about adding a dedicated debugging helper for WebKit in general, not Qt related so it could benefit everyone not just a given port. So I propose wtf() and its stream operator. Usage : wtf()HelloWorld34.53322323; will output : Hello World 3 4.53322 IntRect rect(10, 20, 50, 100); wtf()Rectrect; will output : Rect IntRect(10,20 50x100) VectorString v; v.append(3); v.append(4); v.append(5); wtf()v; will output : Vector (3, 4, 5); These are basic examples but we can really extend it to virtually anything, like higher level classes. Here is the bug with a patch attached : https://bugs.webkit.org/show_bug.cgi?id=90823 wtf() is not meant to stay in a given function/patch. It is for developers only who wants to debug, we don't want to add overhead in release build and we do have the LOG macro doing a job similar. An other alternative could be to extend dataLog to support this streaming operator case. I'm open to this alternative too. It's a work in progress but I want to get feedback before I continue further (adding some stream operator overload for example) and also I need to make sure it builds on all ports. Do you think it is useful? Do you think it will ease/make you faster when debugging when you use printf? Do you want that in WebKit? I'm open to suggestion and maybe later improvements (such as showing the line numbers, fct names...). If people think that is useless then forget about it. Thanks. -- Alexis Menard (darktears) Software Engineer openBossa @ INdT - Instituto Nokia de Tecnologia ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] SVG video chat (2)
Last month we had a video chat with the SVG team in WebKit and it was very well received. If there are other highly-coupled, highly-distributed sub-components of WebKit I would highly recommend setting one of these up. SVG, The last video chat went great and as a group we decided to do it again. If you'd like to join please add your name, availability, and topics you'd like to discuss to the spreadsheet: * https://docs.google.com/spreadsheet/ccc?key=0AorN2u5hCJiUdDQ3RUM0bzlGZUpENnAtTHh5aFJBU0E * Thanks, Philip ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] SVG video chat (2)
Last month we had a video chat with the SVG team in WebKit and it was very well received. If there are other highly-coupled, highly-distributed sub-components of WebKit I would highly recommend setting one of these up. SVG, The last video chat went great and as a group we decided to do it again. If you'd like to join please add your name, availability, and topics you'd like to discuss to the spreadsheet: * https://docs.google.com/spreadsheet/ccc?key=0AorN2u5hCJiUdDQ3RUM0bzlGZUpENnAtTHh5aFJBU0E * Thanks, Philip ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebKit SVG chatroulette
If you don't work on SVG in WebKit you can stop reading now. WebKit, Is there interest in a 1hr video chat with WebKit people interested in SVG as a followup to the WebKit contributors meeting? A few active SVG contributors weren't able to make the meeting and we have some really cool topics to talk about (SVG2.0, RenderLayer work, etc.) If this sounds interesting to you or you just want to say moin to #ksvg friends, please add your name and availability: https://docs.google.com/spreadsheet/ccc?key=0AorN2u5hCJiUdGRVRmJsendBYnB1dFFacE1mdV9PUEE Thanks, Philip ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit SVG chatroulette
Done! I put it on the same spreadsheet to keep everything in one place. Philip On Thu, Apr 26, 2012 at 2:55 PM, Dirk Schulze dschu...@adobe.com wrote: On Apr 26, 2012, at 11:49 AM, Philip Rogers wrote: If you don't work on SVG in WebKit you can stop reading now. WebKit, Is there interest in a 1hr video chat with WebKit people interested in SVG as a followup to the WebKit contributors meeting? A few active SVG contributors weren't able to make the meeting and we have some really cool topics to talk about (SVG2.0, RenderLayer work, etc.) Great idea! Can you set up another table with possible topics? Greetings, Dirk If this sounds interesting to you or you just want to say moin to #ksvg friends, please add your name and availability: https://docs.google.com/spreadsheet/ccc?key=0AorN2u5hCJiUdGRVRmJsendBYnB1dFFacE1mdV9PUEE Thanks, Philip ___ 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] Git/SVN is slow
Bill, I'm currently pulling from svn.webkit.org at what feels like 5kbps, and poor http://build.webkit.org/console hits the page refresh before it's even able to render to the bottom :( Below is a traceroute to webkit.org: traceroute to svn.webkit.org (17.254.20.241), 30 hops max, 60 byte packets 1 DD-WRT (192.168.2.1) 0.233 ms 0.297 ms 0.371 ms 2 10.1.10.1 (10.1.10.1) 2.446 ms 2.445 ms 2.518 ms 3 96.176.191.1 (96.176.191.1) 24.451 ms 25.398 ms 28.688 ms 4 xe-11-0-0-0-sur01.a2atlanta.ga.atlanta.comcast.net (68.85.91.177) 14.588 ms 15.541 ms 15.733 ms 5 xe-2-1-3-0-ar01.b0atlanta.ga.atlanta.comcast.net (68.86.106.57) 16.563 ms 16.929 ms 16.946 ms 6 pos-3-6-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.93.201) 17.967 ms pos-3-5-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.93.125) 14.599 ms 11.428 ms 7 4.28.24.77 (4.28.24.77) 15.973 ms 17.858 ms 17.307 ms 8 vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62) 19.688 ms vlan52.ebr2.Atlanta2.Level3.net (4.69.150.126) 14.891 ms vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62) 15.116 ms 9 ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253) 14.651 ms ae-63-63.ebr3.Atlanta2.Level3.net (4.69.148.241) 13.767 ms ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253) 14.955 ms 10 ae-7-7.ebr3.Dallas1.Level3.net (4.69.134.21) 34.004 ms 36.807 ms 34.950 ms 11 ae-3-3.ebr2.LosAngeles1.Level3.net (4.69.132.77) 66.601 ms 65.766 ms 66.692 ms 12 ae-6-6.ebr2.SanJose5.Level3.net (4.69.148.202) 78.577 ms 78.007 ms 78.175 ms 13 ae-1-100.ebr1.SanJose5.Level3.net (4.69.148.109) 78.594 ms 78.520 ms ae-5-5.ebr4.SanJose1.Level3.net (4.69.148.142) 81.371 ms 14 ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33) 71.989 ms ae-5-5.ebr1.SanJose1.Level3.net (4.69.148.138) 77.341 ms ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33) 77.662 ms 15 ae-62-62.csw1.SanJose1.Level3.net (4.69.153.18) 80.375 ms ae-61-61.csw1.SanJose1.Level3.net (4.69.153.2) 87.895 ms ae-81-81.csw3.SanJose1.Level3.net (4.69.153.10) 77.137 ms 16 ae-31-90.car1.SanJose2.Level3.net (4.69.152.203) 77.660 ms ae-41-80.car1.SanJose2.Level3.net (4.69.152.139) 78.313 ms ae-21-60.car1.SanJose2.Level3.net (4.69.152.11) 77.746 ms 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * Thanks for looking into this. Philip On Thu, Mar 15, 2012 at 10:23 AM, William Siegrist wsiegr...@apple.comwrote: Our network provider did not find anything wrong. If anyone is currently seeing slow download times, I would like to see a traceroute to the server. Thanks, -Bill ___ 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] Please set the svn:mime-type property on binary files before committing
Ojan, There are also quite a few files with the svn:executable property set (359 in LayoutTests alone, by my count), I think most of which are erroneous. Philip On Thu, Mar 8, 2012 at 3:05 PM, Ojan Vafai o...@chromium.org wrote: Whoops. A lot of these were from me yesterday. Sorry, I didn't realize I didn't have my subversion config set correctly. I went to fix up my commits from yesterday and realized that a very large percentage of the pngs in the LayoutTests tree have the wrong svn:mime-type. Is anyone opposed to me doing a bulk fix for all the pngs? find LayoutTests | grep \.png$ | grep -v \.svn | xargs svn ps svn:mime-type image/png On Thu, Mar 8, 2012 at 1:52 AM, Ashod Nakashian ashodnakash...@yahoo.comwrote: Please let's also enforce svn:eol-style to LF for all scripts as this is breaking (at least) the bash scripts that are checked-out with native style on Windows. Some bash versions don't like CR. Please see a (failed) attempt at fixing this manually[1]. I also believe we should mark all (Bash/Perl/Python) scripts as executable. It's best to at least automate it, if not also check for violations via check-webkit-style. (And for the loving of all that's good, would someone please help with this bug[1]?) [1] https://bugs.webkit.org/show_bug.cgi?id=79509 -Ash -- *From:* Simon Fraser simon.fra...@apple.com *To:* Eric Seidel e...@webkit.org *Cc:* WebKit Development webkit-dev@lists.webkit.org *Sent:* Thursday, March 8, 2012 3:37 AM *Subject:* Re: [webkit-dev] Please set the svn:mime-type property on binary files before committing The best way to enforce it would be with a pre-commit hook: https://bugs.webkit.org/show_bug.cgi?id=80548 Simon On Mar 7, 2012, at 3:33 PM, Eric Seidel wrote: Unless this is enforced by a tool, it's very likely to be forgotten. https://bugs.webkit.org/show_bug.cgi?id=75824 https://bugs.webkit.org/show_bug.cgi?id=75825 On Wed, Mar 7, 2012 at 3:21 PM, Dan Bernstein m...@apple.com wrote: Please set the svn:mime-type property on binary files that you add to the tree, such as *-expected.png, before committing. Otherwise the resulting webkit-changes message will include those files as text, which is inconvenient. 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 ___ 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] *.webkit.org is down
http://www.downforeveryoneorjustme.com/ (It's up for me too). On Thu, Jan 19, 2012 at 3:22 PM, Jarred Nicholls jar...@webkit.org wrote: On Thu, Jan 19, 2012 at 3:19 PM, Alexis Menard alexis.men...@openbossa.org wrote: Hi, It seems that *.webkit.org are down (bugs.webkit.org, trace.webkit.org, …). I can confirm here in Maryland, USA that www, bugs, trac, etc. are all up. Here in Brazil we can't access to any of them. I tried two different internet providers with their own DNS and I even tried google DNS with no luck. Might you try OpenDNS? 208.67.222.222/208.67.220.220 Talking to some people in #webkit it seems that not everyone is affected (maybe only people outside US?). Anyone who knows where the servers sits would mind to have a look at them? Thank you very much. ___ 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] New to Webkit development: Eclipse under Linux?
Dave, I've used EclipseCDT for Chromium and it works fairly well (syntax highlighting, debugging, etc). The instructions on this page have everything you'll need and should work for WebKit as well: http://code.google.com/p/chromium/wiki/LinuxEclipseDev Eclipse's GUI frontend to gdb does have some rough edges but overall works pretty well. Philip On Sat, Dec 3, 2011 at 5:25 PM, Dave Tharp dth...@codeaurora.org wrote: Has anyone successfully configured Eclipse CDT for Webkit development and debugging (gdb) under Linux? I'd be interested in either : a) Some pointers for setting up Eclipse - or - b) Suggestions for a better (best?) alternative for development/debugging under Linux (other than vi / command line gdb. And buy a Mac isn't helpful either :-) ) I've looked at ddd, and nemiver. They are perhaps viable, but I'd like more of a capable IDE, and Eclipse seems a good way to go on the surface. I'd like some advice from the community before I invest the time into configuring from scratch if possible. Thanks in advance, -Dave Tharp __**_ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/**mailman/listinfo.cgi/webkit-**devhttp://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
