Re: [webkit-dev] Queries regarding indexed db implementation

[Jiyeon Kim]

On Thursday, May 03, 2012 at 1:59AM, Alec Flett alecfl...@chromium.org wrote:

Hi all.

 

This is Jiyeon Kim recently joined webkit-dev mailing list.

 

Welcome - I'm somewhat new here myself, but I am working on IndexedDB support 
in WebKit..

 

 

I’ve got two questions on IndexedDB.

First, I wonder, while Web storage and Web SQL have tracker, why Indexed DB 
doesn’t have tracker.

 

What do you mean by "tracker" ?

ð  Thank you for your reply.

 

Second, if you look at IDBFactory::open() method in IDBFactory.cpp file,

the fifth argument of m_backend->open(name, request.get(), 
context->securityOrigin(), frame, String()); is not about path information but 
a string (i.e., 
document->page()->group().groupSettings()->indexedDBDatabasePath();).

I also wonder why it is a string rather than a path.

The m_backend is an interface to the actual database implementation - that 
tends to deal with stuff at a slightly lower level (i.e. actual paths on disk, 
etc) - are you looking for a url path? All the IDB's for a security origin are 
accessable to each other, and not connected to the rest of the URL (i.e.  
 http://foo.com/abc has the same security origin as  
 http://foo.com/xyz so they have access to the same set of 
IDB files, so indexedDBDatabasePath() is the same)

 

 Alec

Thanks for your time to look into my questions.

Best regards,
Jiyeon Kim

 

___
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] NPN_InvokeDefault failure

[tmalsbar]

> En 26/04/12 19:47, tmals...@codeaurora.org escribiu:
>> Hello,
>>
>> Calling NPN_InvokeDefault from a plugin fails sometimes using the latest
>> built for gtk (using JavaScriptCore).  The failure occurs because the
>> if (!rootObject || !rootObject->isValid())
>> check fails in NP_jsobject.cpp@_NPN_InvokeDefault.
>
> Looks like a bug, could you please file a bug about that? Also add me on
> CC please.
>

Done: https://bugs.webkit.org/show_bug.cgi?id=85417.  Let me know if you
need any additional info.

Thanks again,
-Todd

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Feature Announcement: Adding

[Maciej Stachowiak]

On May 2, 2012, at 1:03 PM, Adam Barth  wrote:

> One example from this case is seamless navigation.  I implemented
> seamless navigation in two steps:
> 
> 1) Refactoring the existing codepaths to go through a common function.
> 2) Teaching the common function how to redirect navigation for
> seamless iframes (e.g., hyperlinks inside a seamless iframe navigate
> the parent frame).
> 
> Step (1) is hard to protect with ifdefs whereas step (2) is easy.
> Fortunately, in this specific case, we landed step (1) a while ago, so
> it's had some time to bake already.

In this specific example, it seems reasonable to ifdef only the work of step 
(2), particularly since, as you note, step (1) has already landed.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Feature Announcement: Adding

[Adam Barth]

On Wed, May 2, 2012 at 12:11 PM, Maciej Stachowiak  wrote:
> On May 2, 2012, at 11:48 AM, Jarred Nicholls  wrote:
> On Wed, May 2, 2012 at 2:03 PM, Maciej Stachowiak  wrote:
>> On May 2, 2012, at 6:14 AM, Jarred Nicholls  wrote:
>> On Tue, May 1, 2012 at 7:39 PM, Maciej Stachowiak  wrote:
>>> I'm not too picky about how it's done, but I'd feel more comfortable with
>>> #ifdef protecting the code changes rather than if(). If the changes are so
>>> entangled that it's not easy to put only the changes in an ifdef, then I
>>> would be skeptical that they actually have no possible effect on the
>>> non-seamless case.
>>
>> Do we not have sufficient tests to lend us more confidence in this area?
>>
>> There's no amount of automated testing that would make me comfortable with
>> landing a major feature today and shipping it to customers tomorrow
>> (exaggerated case, but this is the kind of thing we're talking about).
>
>
> I wholeheartedly agree, and agree #ifdefs provide safety in this regard.
>
> I was speaking more towards the skepticism that the runtime conditional
> checks were not adversely affecting the non-seamless case.  I would hope to
> think that our automated tests were (or will be) abundant and thorough
> enough to prove with some level of confidence that what Adam suggests would
> work.  If that isn't the outcome, then one could argue tests are worthless
> in all situations.
>
>
> I'm not necessarily automatically skeptical. I see two possible cases:
>
> 1) Code relevant to the feature is entangled with many parts of existing
> code ==> greater probability of error ==> more value to #ifdefs
> 2) Code relevant to the feature well isolated ==> #ifdefs should be few in
> number and easy to place ==> lower cost to #ifdefs
>
> I don't know what the case against thoroughly deploying #ifdefs is, so I'm
> not sure which of these applies. And maybe I made a mistake and these
> possibilities are not exhaustive.
>
> #ifdefs are valuable and necessary for the reasons you stated, particularly
> security and bugs in new exposed features.  These things ought to be
> gradually exposed, starting with explicit opt-ins.  But, aside from that and
> as a separate issue really, I would hope to think that our tests properly
> mitigate concern for regressions on code that is being modified.
>
>
> I have already explained why I think automated regression tests are not
> sufficient risk mitigation for nontrivial new features by themselves,
> namely, they have not been sufficient in the past. See for example the HTML5
> parser, which was awesome but needed significant bake time to flush out the
> site compatibility regressions and other bugs.
>
> But I would look at it another way: #ifdef is our usual approach to making
> it possible to turn off new code that needs bake time. Folks are welcome to
> propose something other than the usual in specific cases. But there should
> be a positive reason given why a different approach is better. Do you know
> of a specific reason why #ifdefs are not appropriate in this case?

One example from this case is seamless navigation.  I implemented
seamless navigation in two steps:

1) Refactoring the existing codepaths to go through a common function.
2) Teaching the common function how to redirect navigation for
seamless iframes (e.g., hyperlinks inside a seamless iframe navigate
the parent frame).

Step (1) is hard to protect with ifdefs whereas step (2) is easy.
Fortunately, in this specific case, we landed step (1) a while ago, so
it's had some time to bake already.

Adam


> P.S. I have in the past had the personal joy of adding back #ifdefs around a
> feature that had been prematurely enabled unconditionally because it was
> insufficient quality to ship. This is part of why I'm touchy about the idea
> of landing significant new features with no ifdefs. I think we should try to
> avoid that sort of thing and make it feasible to ship something close to
> WebKit trunk at any given time, without need for lengthy branching or
> extensive modifications.
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Feature Announcement: Adding

[Maciej Stachowiak]

On May 2, 2012, at 11:48 AM, Jarred Nicholls  wrote:

> On Wed, May 2, 2012 at 2:03 PM, Maciej Stachowiak  wrote:
> 
> On May 2, 2012, at 6:14 AM, Jarred Nicholls  wrote:
> 
>> On Tue, May 1, 2012 at 7:39 PM, Maciej Stachowiak  wrote:
>> 
>> 
>> I'm not too picky about how it's done, but I'd feel more comfortable with 
>> #ifdef protecting the code changes rather than if(). If the changes are so 
>> entangled that it's not easy to put only the changes in an ifdef, then I 
>> would be skeptical that they actually have no possible effect on the 
>> non-seamless case.
>> 
>> Do we not have sufficient tests to lend us more confidence in this area?
> 
> There's no amount of automated testing that would make me comfortable with 
> landing a major feature today and shipping it to customers tomorrow 
> (exaggerated case, but this is the kind of thing we're talking about).
> 
> I wholeheartedly agree, and agree #ifdefs provide safety in this regard.
> 
> I was speaking more towards the skepticism that the runtime conditional 
> checks were not adversely affecting the non-seamless case.  I would hope to 
> think that our automated tests were (or will be) abundant and thorough enough 
> to prove with some level of confidence that what Adam suggests would work.  
> If that isn't the outcome, then one could argue tests are worthless in all 
> situations.

I'm not necessarily automatically skeptical. I see two possible cases:

1) Code relevant to the feature is entangled with many parts of existing code 
==> greater probability of error ==> more value to #ifdefs
2) Code relevant to the feature well isolated ==> #ifdefs should be few in 
number and easy to place ==> lower cost to #ifdefs

I don't know what the case against thoroughly deploying #ifdefs is, so I'm not 
sure which of these applies. And maybe I made a mistake and these possibilities 
are not exhaustive.

> #ifdefs are valuable and necessary for the reasons you stated, particularly 
> security and bugs in new exposed features.  These things ought to be 
> gradually exposed, starting with explicit opt-ins.  But, aside from that and 
> as a separate issue really, I would hope to think that our tests properly 
> mitigate concern for regressions on code that is being modified.


I have already explained why I think automated regression tests are not 
sufficient risk mitigation for nontrivial new features by themselves, namely, 
they have not been sufficient in the past. See for example the HTML5 parser, 
which was awesome but needed significant bake time to flush out the site 
compatibility regressions and other bugs.

But I would look at it another way: #ifdef is our usual approach to making it 
possible to turn off new code that needs bake time. Folks are welcome to 
propose something other than the usual in specific cases. But there should be a 
positive reason given why a different approach is better. Do you know of a 
specific reason why #ifdefs are not appropriate in this case?

Regards,
Maciej

P.S. I have in the past had the personal joy of adding back #ifdefs around a 
feature that had been prematurely enabled unconditionally because it was 
insufficient quality to ship. This is part of why I'm touchy about the idea of 
landing significant new features with no ifdefs. I think we should try to avoid 
that sort of thing and make it feasible to ship something close to WebKit trunk 
at any given time, without need for lengthy branching or extensive 
modifications.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Feature Announcement: Adding

[Jarred Nicholls]

On Wed, May 2, 2012 at 2:03 PM, Maciej Stachowiak  wrote:

>
> On May 2, 2012, at 6:14 AM, Jarred Nicholls  wrote:
>
> On Tue, May 1, 2012 at 7:39 PM, Maciej Stachowiak  wrote:
>
>>
>>
>> I'm not too picky about how it's done, but I'd feel more comfortable with
>> #ifdef protecting the code changes rather than if(). If the changes are so
>> entangled that it's not easy to put only the changes in an ifdef, then I
>> would be skeptical that they actually have no possible effect on the
>> non-seamless case.
>
>
> Do we not have sufficient tests to lend us more confidence in this area?
>
>
> There's no amount of automated testing that would make me comfortable with
> landing a major feature today and shipping it to customers tomorrow
> (exaggerated case, but this is the kind of thing we're talking about).
>

I wholeheartedly agree, and agree #ifdefs provide safety in this regard.

I was speaking more towards the skepticism that the runtime conditional
checks were not adversely affecting the non-seamless case.  I would hope to
think that our automated tests were (or will be) abundant and thorough
enough to prove with some level of confidence that what Adam suggests would
work.  If that isn't the outcome, then one could argue tests are worthless
in all situations.

#ifdefs are valuable and necessary for the reasons you stated, particularly
security and bugs in new exposed features.  These things ought to be
gradually exposed, starting with explicit opt-ins.  But, aside from that
and as a separate issue really, I would hope to think that our tests
properly mitigate concern for regressions on code that is being modified.


>
> Nearly every significant feature has had security holes or site
> compatibility issues discovered post-landing, even if it passes all tests.
> That's why things like this need bake time; it can take from a few weeks to
> a few months of being enabled on trunk for a new feature to get really
> solid. This is not a disparagement of anyone's coding skills or test
> coverage, that's just the reality. The problems that take a while to flush
> out can often be issues due to specific sites doing unexpected and strange
> things.
>
> Because we don't have a centralized release schedule for WebKit, that
> means there isn't necessarily a single window that is a good time for all
> vendors to take such a risk. That is why ifdefs are valuable even if a
> feature is ready to be on by default in testing builds like WebKit
> nightlies or Chromium canary channel.
>
> Regards,
> Maciej
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Feature Announcement: Adding

[Maciej Stachowiak]

On May 2, 2012, at 6:14 AM, Jarred Nicholls  wrote:

> On Tue, May 1, 2012 at 7:39 PM, Maciej Stachowiak  wrote:
> 
> 
> I'm not too picky about how it's done, but I'd feel more comfortable with 
> #ifdef protecting the code changes rather than if(). If the changes are so 
> entangled that it's not easy to put only the changes in an ifdef, then I 
> would be skeptical that they actually have no possible effect on the 
> non-seamless case.
> 
> Do we not have sufficient tests to lend us more confidence in this area?

There's no amount of automated testing that would make me comfortable with 
landing a major feature today and shipping it to customers tomorrow 
(exaggerated case, but this is the kind of thing we're talking about).

Nearly every significant feature has had security holes or site compatibility 
issues discovered post-landing, even if it passes all tests. That's why things 
like this need bake time; it can take from a few weeks to a few months of being 
enabled on trunk for a new feature to get really solid. This is not a 
disparagement of anyone's coding skills or test coverage, that's just the 
reality. The problems that take a while to flush out can often be issues due to 
specific sites doing unexpected and strange things.

Because we don't have a centralized release schedule for WebKit, that means 
there isn't necessarily a single window that is a good time for all vendors to 
take such a risk. That is why ifdefs are valuable even if a feature is ready to 
be on by default in testing builds like WebKit nightlies or Chromium canary 
channel.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] NPN_InvokeDefault failure

[Sergio Villar Senin]

En 26/04/12 19:47, tmals...@codeaurora.org escribiu:
> Hello,
> 
> Calling NPN_InvokeDefault from a plugin fails sometimes using the latest
> built for gtk (using JavaScriptCore).  The failure occurs because the
> if (!rootObject || !rootObject->isValid())
> check fails in NP_jsobject.cpp@_NPN_InvokeDefault.

Looks like a bug, could you please file a bug about that? Also add me on
CC please.

BR
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Queries regarding indexed db implementation

[Alec Flett]

On Wed, May 2, 2012 at 4:42 AM, 김지연  wrote:

> Hi all.
>
> ** **
>
> This is Jiyeon Kim recently joined webkit-dev mailing list.
>
> **
>

Welcome - I'm somewhat new here myself, but I am working on IndexedDB
support in WebKit..

 **
>
> I’ve got two questions on IndexedDB.
>
> First, I wonder, while Web storage and Web SQL have tracker, why Indexed
> DB doesn’t have tracker.
>
>
What do you mean by "tracker" ?



> Second, if you look at *IDBFactory::*open*() method in IDBFactory.cpp*
>  file,
>
> the fifth argument of *m_backend->open(name, request.get(),
> context->securityOrigin(), frame, String());* is not about path
> information but a string (i.e.,*
>  document->page()->group().groupSettings()->indexedDBDatabasePath()*;).***
> *
>
> I also wonder why it is a string rather than a path.
>
> The m_backend is an interface to the actual database implementation - that
tends to deal with stuff at a slightly lower level (i.e. actual paths on
disk, etc) - are you looking for a url path? All the IDB's for a security
origin are accessable to each other, and not connected to the rest of the
URL (i.e. http://foo.com/abc has the same security origin as
http://foo.com/xyz so they have access to the same set of IDB files, so
indexedDBDatabasePath() is the same)

 Alec

> Thanks for your time to look into my questions.
>
> Best regards,
> Jiyeon Kim
>
> ___
> 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] Implementing CSS3 Paged Media Margin Boxes

[Milian Wolff]

On Tuesday 01 May 2012 11:16:07 Simon Fraser wrote:
> Dave Hyatt is interested in doing more Paged Media stuff.
> 
> Any work in this area should be preceded by a conversation with Dave.

OK, thanks. I've send him an email and await input from him.

Cheers

> On Apr 27, 2012, at 11:47 AM, Eric Seidel wrote:
> > Ref-tests did not exist in WebKit when I last looked at this.  I added
> > pdf printing tests, only to realize that pdfs include user/machine
> > information and thus are useless for x-machine testing.
> > 
> > If our ref-test mechanism works for large pages that could work well.
> > 
> > :)  With printing tests you'll want to be able to test taht page 27
> > 
> > has the right number and that it was laid out on the 4th printed page,
> > etc. :)
> > 
> > On Fri, Apr 27, 2012 at 10:29 AM, Milian Wolff  
wrote:
> >> On Friday 27 April 2012 10:08:13 Eric Seidel wrote:
> >>> When I last looked at the page media stuff (long ago).  The problem
> >>> was mostly going to be testing.  We don't have a good way to do
> >>> printing tests right now in WebKit.
> >> 
> >> Someone in the webkit community introduced me to the idea of reftests,
> >> which seem to be a viable option for proper printing tests. I think of
> >> something like the following that should work since we know the pixel
> >> dimensions of a printed page in our unit tests to be 800x600:
> >> 
> >> // @page margin test
> >> 
> >> 
> >> 
> >> * { margin:0; padding:0; }
> >> @page { margin: 10px; }
> >> div {  width: 800px; height: 600px; background: green; }
> >> 
> >> 
> >> 
> >> should have a 10px margin
> >> 
> >> 
> >> 
> >> 
> >> // alternative
> >> 
> >> 
> >> 
> >> * { margin:0; padding:0; }
> >> div { width: 780px; height: 580px; margin: 10px; }
> >> 
> >> 
> >> 
> >> should have a 10px margin
> >> 
> >> 
> >> 
> >> 
> >> Now both versions can be "printed" to PNG similar to what the existing
> >> LayoutTestController.setPrinting() does. The resulting two platform
> >> specific images can be compared and should match - if not, something
> >> went wrong.
> >> 
> >> Am I missing something, is the above impractical?
> >> 
> >> Cheers
> >> 
> >>> On Fri, Apr 27, 2012 at 7:22 AM, Milian Wolff  
wrote:
>  Hey all,
>  
>  I would like to work on the CSS3 Paged Media support, esp. the margin
>  boxes. I'm studying the code for some time now and would welcome it if
>  someone could assist me in figuring out what needs to be done...
>  
>  First up, I think I should tackle the missing support in the parser,
>  i.e.
>  solving the FIXME in CSSParser::createMarginAtRule. I found that
>  CSSFontFaceRule looks similar and could write some code based on that.
>  A
>  few questions arise now:
>  
>  a) For the unit tests (probably not only there) I need to have a
>  special
>  margin-at CSSRule for cssText(). I'll probably be able to copy most of
>  the
>  stuff again, but where in the build system do I have to add these new
>  files?
>  
>  b) What CSSRule::Type should the above have? WEBKIT_MARGINAT_RULE at
>  the
>  end (hence value 11)?. I could not find an official IDL proposal that
>  includes the margin at rules.
>  
>  c) These margin-at rules can only occur inside a page rule, and I need
>  to
>  access them from somewhere - what is the suggested path to take here?
>  create StyleRulePage::setMarginRules or similar? Or reuse stuff from
>  StyleRuleBlock?
>  
>  d) When I have some partial patch ready, where could I get input?
>  Should I
>  attach it to a bug report (I've opened
>  https://bugs.webkit.org/show_bug.cgi?id=85062 for that purpose)
>  
>  f) I see that there are files like JSCSSFontFaceRuleCustom.cpp - what
>  do I
>  need to do there to get the new MediaAtRule accessible from JavaScript?
>  
>  Bye
>  --
>  Milian Wolff | milian.wo...@kdab.com | Software Engineer
>  KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
>  Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
>  KDAB - Qt Experts - Platform-independent software solutions
>  
>  ___
>  webkit-dev mailing list
>  webkit-dev@lists.webkit.org
>  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >> 
> >> --
> >> Milian Wolff | milian.wo...@kdab.com | Software Engineer
> >> KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
> >> Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
> >> KDAB - Qt Experts - Platform-independent software solutions
> >> 
> >> ___
> >> 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
-- 
Milian Wolff 

Re: [webkit-dev] Feature Announcement: Adding

[Jarred Nicholls]

On Tue, May 1, 2012 at 7:39 PM, Maciej Stachowiak  wrote:

>
> On May 1, 2012, at 4:04 PM, Adam Barth  wrote:
>
> > On Tue, May 1, 2012 at 3:50 PM, Maciej Stachowiak  wrote:
> >> On May 1, 2012, at 3:31 PM, Eric Seidel  wrote:
> >>> Is your goal to be able to disable the feature to prevent a late-known
> >>> security issue?
> >>>
> >>> Or is your goal to universally disable seamless for a port entirely?
> >>
> >> I'm not sure I understand the difference between these. The capability
> I'm looking for is to disable the entire feature if necessary. However, I
> don't expect that any ports Apple is involved with would leave it off
> indefinitely. I hope that answers your questions.
> >
> > One approach to ENABLE_SEAMLESS is to put the "seamless" property on
> > HTMLIFrameElement behind [Conditional=SEAMLESS] and then to change
> > Document::mayDisplaySeamlessWithParent to always return false.  That
> > should make the feature invisible to the web.  The changes to the
> > layout and navigation algorithms wouldn't be ifdefed, but they'll do
> > the same things they do today because the engine won't ever treat an
> > iframe as seamless.
>
> I'm not too picky about how it's done, but I'd feel more comfortable with
> #ifdef protecting the code changes rather than if(). If the changes are so
> entangled that it's not easy to put only the changes in an ifdef, then I
> would be skeptical that they actually have no possible effect on the
> non-seamless case.


Do we not have sufficient tests to lend us more confidence in this area?


> If they aren't that entangled, then adding the right #ifdef should be
> straightforward.
>
> 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

[webkit-dev] Queries regarding indexed db implementation

[김지연]

Hi all.

 

This is Jiyeon Kim recently joined webkit-dev mailing list.

 

I’ve got two questions on IndexedDB.

First, I wonder, while Web storage and Web SQL have tracker, why Indexed DB
doesn’t have tracker.

Second, if you look at IDBFactory::open() method in IDBFactory.cpp file, 

the fifth argument of m_backend->open(name, request.get(), context-
>securityOrigin(), frame, String()); is not about path information but a
string (i.e., document->page()->group().groupSettings()-
>indexedDBDatabasePath();). 

I also wonder why it is a string rather than a path.

Thanks for your time to look into my questions.

Best regards,
Jiyeon Kim

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev