Re: [webkit-dev] [Styling] () for a lambda without arguments (Was Space between [] and () in C++ lambdas)
I've been using the short form in the layout code for a while now and never
mistaken it for code block start & end.
That being said I don't have strong preference on this.
Alan.
On Fri, Nov 1, 2019 at 4:37 PM Ryosuke Niwa wrote:
> On Fri, Nov 1, 2019 at 11:53 AM Michael Catanzaro
> wrote:
>
>> On Fri, Nov 1, 2019 at 11:19 am, Ryosuke Niwa wrote:
>> > Namely, some people write a lambda as:
>> > auto x = [] () { }
>> >
>> > with a space between [] and () while others would write it as:
>> >
>> > auto x = []() { }
>>
>> 🔧: I omit the () when there are no parameters, as in these examples.
>>
>
> I guess that's another thing we should decide. Should we, or should we not
> have () when there are no arguments.
>
> I think we usually err on the side of more concise form but I do prefer
> having () so that it's clear it's a function. Otherwise, it can look like a
> code block start & end.
>
> - R. Niwa
>
> ___
> 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] Code Style: Opinion on returning void
I use this idiom too in the layout code. I guess I just prefer a more
compact code.
(I don't feel too strongly about it though)
Alan.
On Thu, Feb 7, 2019 at 7:31 PM Alex Christensen
wrote:
> If you search for “return completionHandler” in WebKit you will find over
> a hundred instances. Most if not all of them return void. It means call
> the completion handler and return. I probably wrote most of them and
> obviously think it’s a fabulous idiom.
>
> > On Feb 7, 2019, at 2:32 PM, Geoffrey Garen wrote:
> >
> > FWIW, I’ve always felt conflicted about this case.
> >
> > I very much prefer early return to if/else chains.
> >
> > However, “return f()” when f returns void is a bit mind bending.
> >
> > So, I can’t use my preferred style in functions that return void. Boo.
> >
> > Geoff
> >
> >> On Feb 7, 2019, at 12:47 PM, Daniel Bates wrote:
> >>
> >> Hi all,
> >>
> >> Something bothers me about code like:
> >>
> >> void f();
> >> void g()
> >> {
> >>if (...)
> >>return f();
> >>return f();
> >> }
> >>
> >> I prefer:
> >>
> >> void g()
> >> {
> >>if (...) {
> >>f();
> >>return
> >>}
> >>f();
> >> }
> >>
> >> Does it bother you? For the former? For the latter? Update our style
> guide?
> >>
> >> Opinions, please.
> >>
> >> Dan
> >> ___
> >> 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 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] Rounded dots in dotted border
Hi, There’s a bit of a history here. https://bugs.webkit.org/show_bug.cgi?id=95203 I don’t see anyone working on this issue, but Myles might have plans. Zalan. > On Jul 14, 2016, at 6:21 AM, Konstantin Tokarev wrote: > > Hello, > > Document [1] says defines "dotted" style as "a series of round dots", however > CG and Cairo implementations draw dots as squares. > > Are there any plans to implement rounded dots? > > > [1] https://www.w3.org/TR/css3-background/#border-style > > - > > P.S. Some context in case anyone is interested: > > I was rewriting drawLine() implementation in Qt port which was broken by > r177686 (remember skewed border in Bugzilla with Cairo? That thing), and > found that implementations of drawLine() share the same logic and differ in > minor details only. However, out old code was drawing rounded dots, and I > feel it would be more appropriate to implement this logic in shared code, or > drop it completely if other ports are not planning to do this. > > -- > Regards, > Konstantin > ___ > 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] MathML layout refactor proposal
It’s great to hear that MathML is getting some proper cleanup. I think the
proposal sounds good and I am looking forward to the patches.
Minor observation: I noticed that, since MathML block is no longer a flexbox,
but it still needs some of the flexbox functionality, the following pattern has
been introduced to the generic renderbox/block code.
-if (parent()->isFlexibleBox()) {
+if (parent()->isFlexibleBox() || parent()->isRenderMathMLBlock()) {
I just wish there was another way to handle this.
Zalan.
> On Dec 9, 2015, at 3:35 AM, Alejandro Garcia Castro wrote:
>
>
> Hi,
>
> In the last months we have been working on refactoring the MathML
> layout code to make it more maintainable, because in the current point
> fixing issues or adding new features has been too complex.
>
> We have reached the point where we think we have to discuss whether
> this work makes sense and whether it is interesting for the WebKit
> community. If so, we will start pushing the initial patches from our
> branch to upstream.
>
> The idea behind the refactor is to remove FlexBox dependency and
> create its own layout MathML methods. The main reasons to do this are:
>
> - Reduce code complexity: Adapting FlexBox layout (which is already
> complex) in order to create the MahtML layout made the code too
> complex, a big technical debt that made the improvement of MathML
> more difficult every day.
>
> - Avoid just another FlexBox dependent code: When we had to add
> general layout alignment support we had a lot of problems trying
> to solve some the MathML issues because it was not clear how it
> worked with the FlexBox.
>
> - Improve performance: We do not need all the features FlexBox
> layout adds for most of the MathML blocks but we are executing
> all that code. We also can simplify the render tree structures
> that were created to make the FlexBox layout work.
>
> - Make easier to improve the MathML implementation: Using
> independent renderer classes gives more flexibility to get exact
> positioning and spacing required to get high-quality math
> rendering based on TeX rules and the OpenType MATH table. (cf
> http://www.mathml-association.org/MathMLinHTML5/)
>
> We have a working prototype that basically passes the current MathML
> tests and removes the FlexBox dependency in:
>
> https://github.com/alexgcastro/webkit/tree/MathMLLayout
>
> We have basically one commit per MathML renderer that we had to
> replace. This is still initial code and we need more work and add more
> tests to make sure we are improving the situation.
>
> We want to do it incrementally with 2 steps:
> 1. Remove FlexBox dependency but do not break the tests, this means
> keep the RenderTree structure. This is basically done, and we just
> need review and try to push them.
> 2. Refactor the RenderTree structure, removing the anonymous nodes
> created to make FlexBox work and all the code that it was
> required. We already have the Fractions and Underover implemented
> and the code is much clearer. This will break the tests relying on
> a PNG image or a render tree reference. Hence we will do it also
> per renderer and rebasing the tests after each commit.
>
> The main con of the change that the code could be bigger in some parts
> of the renderers, but more direct and simple, so it should be actually
> good regarding maintenance.
>
> If you have any question, proposal or comment just send it, it would
> be great to hear some more feedback, and check if we should proceed
> with this effort.
>
> Greetings,
>
> Alex
> ___
> 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] Proposal: Remove ENABLE(SATURATED_LAYOUT_ARITHMETIC)
Sounds good. Zalan. > On Nov 9, 2015, at 8:21 AM, Osztrogonác Csaba wrote: > > Hi, > > ENABLE(SUBPIXEL_LAYOUT) guard was removed and > ENABLE(SATURATED_LAYOUT_ARITHMETIC) > is enabled on all ports more than a year ago. I don't know any issue related > to it. > > I'd like to propose to remove the ENABLE(SATURATED_LAYOUT_ARITHMETIC) guards > too. > https://bugs.webkit.org/show_bug.cgi?id=150972 > > Any objection? > > br, > Ossy > > former thread - [webkit-dev] Proposal: Remove ENABLE(SUBPIXEL_LAYOUT) > On 2014-08-18 22:30, Zalan Bujtas wrote: >> Hi, >> >> Quote for from bug #124234 >> "Since the SATURATED_LAYOUT_ARITHMETIC flag makes no sense without >> SUBPIXEL_LAYOUT, actually there is an assertion preventing this, it seems >> that the most sensible action is to merge the SATURATED_LAYOUT_ARITHMETIC >> logic into the SUBPIXEL_LAYOUT, and eventually removing it.” >> Makes sense. I might just remove ENABLE(SATURATED_LAYOUT_ARITHMETIC) too >> (instead of just enable it by default). >> >> Zalan. >> >> On Aug 18, 2014, at 12:47 PM, Javier Fernandez wrote: >> >>> Hi, >>> >>> On 08/18/2014 08:14 PM, Zalan Bujtas wrote: >>>> Hi Everyone, I’d like to propose removing ENABLE(SUBPIXEL_LAYOUT), as >>>> every port has it enabled. As part of this activity, I am planning to >>>> enable SATURATED_LAYOUT_ARITHMETIC by default. Thanks, Zalan. >>> >>> I've already opened a bug to address this issue, but unfortunately, >>> didn't find the time to complete the task. See >>> https://bugs.webkit.org/show_bug.cgi?id=124234 for details. >>> >>> -- >>> javi > ___ > 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] Proposal: Remove ENABLE(SUBPIXEL_LAYOUT)
Hi, Quote for from bug #124234 "Since the SATURATED_LAYOUT_ARITHMETIC flag makes no sense without SUBPIXEL_LAYOUT, actually there is an assertion preventing this, it seems that the most sensible action is to merge the SATURATED_LAYOUT_ARITHMETIC logic into the SUBPIXEL_LAYOUT, and eventually removing it.” Makes sense. I might just remove ENABLE(SATURATED_LAYOUT_ARITHMETIC) too (instead of just enable it by default). Zalan. On Aug 18, 2014, at 12:47 PM, Javier Fernandez wrote: > Hi, > > On 08/18/2014 08:14 PM, Zalan Bujtas wrote: >> Hi Everyone, I’d like to propose removing ENABLE(SUBPIXEL_LAYOUT), as >> every port has it enabled. As part of this activity, I am planning to >> enable SATURATED_LAYOUT_ARITHMETIC by default. Thanks, Zalan. > > I've already opened a bug to address this issue, but unfortunately, > didn't find the time to complete the task. See > https://bugs.webkit.org/show_bug.cgi?id=124234 for details. > > -- > javi > ___ > 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] Proposal: Remove ENABLE(SUBPIXEL_LAYOUT)
Hi Everyone, I’d like to propose removing ENABLE(SUBPIXEL_LAYOUT), as every port has it enabled. As part of this activity, I am planning to enable SATURATED_LAYOUT_ARITHMETIC by default. Thanks, Zalan. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] S60WebKit MIME type question
>One thing to look out for is that I don't thin the NPAPI is fully implemented >on S60. it is pretty much fully implemented on S60 AFAIK, though the API got "symbianized" for some reason, by changing some data types (char*) to Symbian types (HBufC*). http://trac.webkit.org/browser/S60/trunk/WebKit/Plugin/inc/npapi.h Zalan. On Tue, Jul 14, 2009 at 5:08 PM, Jack Wootton wrote: > Just to add, you are right, S60 browser uses ECOM to load a list of > plugins at runtime that implement the interface > 'CEcomBrowserPluginInterface'. It stores meta data about each plugin, > such as the MIME type it handles and the UID of the DLL implementing > the plugin. The browser then loads the plugin if the MIME type found > in the or tag matches. > > One thing to look out for is that I don't thin the NPAPI is fully > implemented on S60. > > On Tue, Jul 14, 2009 at 4:04 PM, Jack Wootton wrote: >> Plugins should follow the NPAPI >> (https://developer.mozilla.org/en/Gecko_Plugin_API_Reference) and so >> it shouldn't really matter if it pre-dates WebKit. No doubt someone >> else on this mailing list can offer more help here (since I'm new to >> webkit). >> >> If you sign up to the Symbian Foundation, then you can browse S60 code >> online. Unfortunately having had a quick look it seems there are no >> reference plugin implementations in the code. There are some s60 >> specific plugin files, using the Symbian Foundation cross referencing >> tool, they can be found in: >> >> /MCL/sf/mw/web/webengine/osswebengine/WebKit/s60/plugins >> (http://developer.symbian.org/xref/oss/xref/MCL/sf/mw/web/webengine/osswebengine/WebKit/s60/plugins/) >> >> On Tue, Jul 14, 2009 at 3:35 PM, Sam Critchley wrote: >>> >>> Hi Jack, >>> >>> Thanks for taking the time to reply. The Nokia Platform Services resources >>> are great, but currently only available in WRT on their S60 5th edition >>> devices (5800 and N97). I think we're also going to look closely at the >>> plug-in route as well - I wonder if there's a repository of standard >>> plug-ins somewhere... >>> >>> I found the following on S60 browser plug-ins: >>> >>> http://www.forum.nokia.com/main/resources/technologies/browser_plug-in_api.html >>> >>> Unfortunately I think this pre-dates the WebKit browser, so I'm not sure it >>> still applies >>> >>> I did find some documentation on Ecom plug-ins as well. I assume that's also >>> available through S60WebKit as well. The main question is whether there's a >>> repository of existing plug-ins somewhere (e.g. if there's a camera plug-in) >>> or if you have to code your own. >>> >>> Thanks, >>> >>> Sam >>> >>> >>> On Jul 14, 2009, at 2:46 PM, Jack Wootton wrote: >>> If a browser finds a MIME type it cannot display (for example from an or tag) then is will iterate through available plugins and load the plugin which handles that MIME type. Regarding camera on S60, you may want to take a look at: Nokia hvave released a beta version of the their new "Platform Services" (JavaScript API to you and me), this includes a camera API (the download includes a sis file which adds the new api to the device, but it also comes with a JavaScript library which allows pictures to be taken using the camera app and displayed using JavaScript). There are also sample widgets which use the camera API. http://www.forum.nokia.com/info/sw.nokia.com/id/cccea743-f4e5-418f-ad9f-0a7a7f50868f/Nokia_Platform_Services_2_0.html For something which isn't in beta, Nokia provide a JavaScript API for launching 3rd party applications (you just supply the UID of the app you wish to launch - I don't know how you can transfer data from the app to the webkit environment though). The API is part of Nokia's Web Developer Library found here: http://library.forum.nokia.com/index.jsp?topic=/Web_Developers_Library/GUID-4D13AF3F-4733-44E7-996F-F27A11C9D6BF_cover.html You want to look at Web Developer's Library 1.7 > Web Runtime widgets > > Developing widgets > Web Runtime API reference > JavaScript Service API reference On Tue, Jul 14, 2009 at 1:21 PM, Sam Critchley wrote: > > Hi, > > Apologies for the very basic question, but I'm trying to find out how you > can use custom MIME types in WebKit on S60 (3rd and 5th editions). We're > looking at doing something like triggering the S60 camera app using a > camera > button in a web form (which is accessed in an app using Webkit for > content > display), take a picture, insert it into the form, and POST it to the > website. Can anyone point me to information on how/whether we could do > this? > > Thanks, > > Sam > > > *** > Sam Critchley > VP, Products and Co-Founder > GyPSii > http://www.gypsii.com/ > scritch...@gypsii.com > GyPSii HQ A
Re: [webkit-dev] Canvas API in Webkit
> Well, those browsers aren't open source, so there's no real way for you to > find out how they implemented the feature. > > I think it's safe to assume that they draw the web pages into a bitmap and > then shrink the image. > > It certainly has nothing to do with the HTML element in either > case. > >-- Darin The function below indicates that s60 browser is using a bitmap to implement the history feature. void CHistoryController::UpdateHistoryEntryThumbnailL(const CFbsBitmap* aBitmap); http://trac.webkit.org/browser/S60/trunk/HistoryProvider/inc/HistoryController.h#L190 Zalan. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] We are porting WebKit to UIQ (Symbian based platform)
Hi, Ozone team has been porting WebKit to UIQ platform and the first, alpha version is available at http://www.o3mobi.com It is based on r34485 (06/10/08). For us, it is important to make sure that our port takes advantage of all the improvements coming to WebKit trunk, so for this reason, we'd like to merge our changes back, rather than having it forked. Thanks, Zalan Bujtas / Ozone team. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] errors in Carbide but not on command line
>>> This seems simple enough and, I can just remove the line '#include >>> '. >>> >>> However, in the JavaScriptCore bld.inf it looks likes this: The targeted sdk (s60 3rd edition) cannot resolve MW_LAYER_SDK_EXPORT_PATH, so the export paths are hardcoded. That's the major difference between the #ifndef and the #else branch. I think you need to clean up the .inf files by removing the #ifndef __BROWSER_SDK' branch. >> How can Nokia port the webkit so that it doesn't build in their own IDE? I guess, Webkit was ported to S60 before, Carbide was taken into use and not been updated since. Zalan. On Thu, Jul 17, 2008 at 11:58 AM, Jack Wootton <[EMAIL PROTECTED]> wrote: > Does anyone have a solution other than just commenting out all the > files that shouldn't be included? This doesn't seem practical since > there are around 60 errors reported from files not being found, it > seems these files are meant to be conditionally included in the build > process but that the '#ifndef __BROWSER_SDK' preprocessor commands are > not working. > > On Thu, Jul 17, 2008 at 10:38 AM, Jack Wootton <[EMAIL PROTECTED]> wrote: >> OK, So from reading this >> >> http://discussion.forum.nokia.com/forum/showthread.php?t=69737 >> >> I understand the situation better. One question: >> >> How can Nokia port the webkit so that it doesn't build in their own IDE? >> >> People moan about Google this and Google that, but this is something >> Google would never do. >> >> On Thu, Jul 17, 2008 at 9:50 AM, Jack Wootton <[EMAIL PROTECTED]> wrote: >>> Hi, >>> >>> The WebKit bld.inf contains the following lines: >>> >>> #ifndef __BROWSER_SDK >>> #include >>> #endif >>> >>> This seems simple enough and, I can just remove the line '#include >>> '. >>> >>> However, in the JavaScriptCore bld.inf it looks likes this: >>> >>> /** Start horrible code extract */ >>> >>> #ifndef __BROWSER_SDK >>> #include >>> ..\kjs\internal.h >>> MW_LAYER_SDK_EXPORT_PATH(javascriptcore\internal.h) >>> ..\kjs\interpreter.h >>> MW_LAYER_SDK_EXPORT_PATH(javascriptcore\interpreter.h) >>> ..\kjs\object.h MW_LAYER_SDK_EXPORT_PATH(javascriptcore\object.h) >>> ..\kjs\protect.h MW_LAYER_SDK_EXPORT_PATH(javascriptcore\protect.h) >>> ..\kjs\stdint.h MW_LAYER_SDK_EXPORT_PATH(javascriptcore\stdint.h) >>> >>> ..\bindings\npruntime.h >>> MW_LAYER_SDK_EXPORT_PATH(javascriptcore\npruntime.h) >>> ..\bindings\npruntime_impl.h >>> MW_LAYER_SDK_EXPORT_PATH(javascriptcore\npruntime_impl.h) >>> ..\bindings\npruntime_priv.h >>> MW_LAYER_SDK_EXPORT_PATH(javascriptcore\npruntime_priv.h) >>> ..\bindings\runtime.h >>> MW_LAYER_SDK_EXPORT_PATH(javascriptcore\runtime.h) >>> ..\bindings\runtime_object.h >>> MW_LAYER_SDK_EXPORT_PATH(javascriptcore\runtime_object.h) >>> ..\bindings\runtime_root.h >>> MW_LAYER_SDK_EXPORT_PATH(javascriptcore\runtime_root.h) >>> ..\bindings\NP_jsobject.h >>> MW_LAYER_SDK_EXPORT_PATH(javascriptcore\NP_jsobject.h) >>> ..\bindings\c\c_utility.h >>> MW_LAYER_SDK_EXPORT_PATH(javascriptcore\c_utility.h) >>> #else >>> ..\kjs\internal.h \epoc32\include\oem\javascriptcore\internal.h >>> ..\kjs\interpreter.h \epoc32\include\oem\javascriptcore\interpreter.h >>> ..\kjs\object.h \epoc32\include\oem\javascriptcore\object.h >>> ..\kjs\protect.h \epoc32\include\oem\javascriptcore\protect.h >>> ..\kjs\stdint.h \epoc32\include\oem\javascriptcore\stdint.h >>> >>> ..\bindings\npruntime.h >>> \epoc32\include\oem\javascriptcore\npruntime.h >>> ..\bindings\npruntime_impl.h >>> \epoc32\include\oem\javascriptcore\npruntime_impl.h >>> ..\bindings\npruntime_priv.h >>> \epoc32\include\oem\javascriptcore\npruntime_priv.h >>> ..\bindings\runtime.h >>> \epoc32\include\oem\javascriptcore\runtime.h >>> ..\bindings\runtime_object.h >>> \epoc32\include\oem\javascriptcore\runtime_object.h >>> ..\bindings\runtime_root.h >>> \epoc32\include\oem\javascriptcore\runtime_root.h >>> ..\bindings\NP_jsobject.h >>> \epoc32\include\oem\javascriptcore\NP_jsobject.h >>> ..\bindings\c\c_utility.h >>> \epoc32\include\oem\javascriptcore\c_utility.h >>> #endif //#ifndef __BROWSER_SDK
Re: [webkit-dev] errors in Carbide but not on command line
>#include it is #ifdef-ed out in the bld.inf. Carbide does not manage #ifdefs in the build files properly. Zalan. On Wed, Jul 16, 2008 at 12:41 PM, Jack Wootton <[EMAIL PROTECTED]> wrote: > To add, the following two files are displaying errors in Carbide: > > S60\JavaScriptCore\group\bld.inf > S60\WebKit\group\bld.inf > > JavaScriptCore bld.inf both have a problem with the following line: > > #include > > Presumably it can't find the file. > > > > On Wed, Jul 16, 2008 at 5:11 PM, Jack Wootton <[EMAIL PROTECTED]> wrote: >> Hi all, >> >> Having successfully built S60 WebKit on the command line (using an >> older version (21772 )), I decided to try building it in Carbide. I >> get the following errors: >> >> /** Start Errors >> **/ >> >> In file included from .\BLD.INF:50: >> .\.\JavaScriptCore\group\bld.inf:28: >> domain/osextensions/platform_paths.hrh: No such file or directory >> >> In file included from .\BLD.INF:52: >> .\.\WEBKIT\group\bld.inf:42: domain/osextensions/platform_paths.hrh: >> No such file or directory >> BLDMAKE ERROR: ERROR: cpp.exe returned non-zero exit status (8448) >>cpp.EXE -undef -nostdinc -+ -I ..\epoc32\include -I . -I .\ -I >> "..\epoc32\include\variant" -include >> ..\epoc32\include\variant\Symbian_OS_v9.1.hrh ".\BLD.INF" >> >> /** End Errors >> **/ >> >> The build target inside Carbide was set to Emulator Debug (WINSCW). >> >> Can anyone help? >> >> -- >> Regards >> Jack >> > > > > -- > Regards > Jack > ___ > 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
