Re: [webkit-dev] Alignment issues in MIPS
2010/4/6 Luciano Montanaro mikel...@gmail.com On Tue, Apr 6, 2010 at 9:21 AM, Alex Vazquez alexvazquezfe...@gmail.com wrote: Hello list, I'm cross-compiling WebKit (revision 40084) for a MIPS board using DirectFB backend. While executing in the target, libwebkit is causing SIGBUS errors due to misaligned double data. The errors raise when loading a misaligned double in the FPU using the ldc1 instruction (it is stated in the MIPS documentation that data loaded in the FPU must be 8-byte aligned to avoid an address error). I know that the kernel can be configured to manage misaligned accesses but i prefer not to mess with that by the moment. I have SIGBUS problems cross-compiling on SH4 with Qt, similar to yours. Debug builds work fine, but release builds crash as soon as the first webkit-related call is made. I've not had time to investigate further, though I'll soon have to. I'm looking into your suggestion, and I see the class is not optimallly laid out (there is a function pointer which is presumably 4 bytes, followed by a double which is 8), though the compiler should correctly align it putting a 4 byte hole between the pointer and the double. At new time, the class should be allocated from a correctly aligned memory block, so any misalignments are probably due to copying the class around? Yes, it seems to be unaligned anywhere else in the code. I'll try to find where and report back. Regards, -- Luciano Montanaro Anyone who is capable of getting themselves made President should on no account be allowed to do the job. -- Douglas Adams -- Alejandro Vazquez Fente ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Rich Text Editing Questions, Refactoring of Position Classes
Thanks for the comments! Please find my replies inline: On Tue, Apr 6, 2010 at 2:51 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 1, 2010, at 10:43 PM, Roland Steiner wrote: .) When a selection that starts in a table and ends outside it is deleted, the current code drags the adjacent outside content into the table. To me this is counter-intuitive (text can be dragged in, but not between cells, and not back outside), and it's also contrary to the behavior of other editors (FireFox, TextEdit, Word, etc.). The behavior is, however, enshrined in various layout tests, so I wonder if there was/is a reason to implement it this way. As this behavior also complicates fixing other bugs I wanted to see whether there would be much opposition to changing it (i.e., to content outside of a table staying outside on a delete operation). Which layout tests? Do they reference bugs? We can study the bugs to see if they truly ask for the behavior being tested. On Tue, Apr 6, 2010 at 3:39 PM, Justin Garcia justin.gar...@apple.com wrote: I think you're right except that if the table doesn't look like a table (like if it doesn't have any cell borders) its content can just look like any other set of paragraphs. Content should be merged in those cases I think. Off the top of my head I believe some Mail behavior depended on this. You could check and see when those layout tests were checked in and bug titles from the corresponding ChangeLog entries might shed some light on this. The following layout tests explicitly require outside content to be moved into table cells: editing/deleting/5032066.html rdar://problem/5032066 Delete should work between To Dos editing/deleting/delete-block-table.html (updated multiple times, the change marked with * is the same as for the above layout test) rdar://problem/4622763 Deleting from beginning of paragraph following a table deletes rather than selects the table Setup for rdar://problem/4344550 Misspellings aren't marked after undo delete rdar://problem/4922367 WebView selectLine: followed by deleteBackward: deletes TABLE element of following line * rdar://problem/5032066 Delete should work between To Dos rdar://problem/5107422 TOT REGRESSION: Delete key fails to delete text, and cursor disappears in Mail.app REGRESSION (r19595): WebViewDidBeginEditingNotification not posted when focusing with the mouse updated some test results that were affected by Hyatt's fix for rdar://problem/5208440 REGRESSION: Raw text needs to be pulled outside of tables (13753) editing/deleting/5206311-2.html rdar://problem/5206311 Whitespace can't be removed when editing text pasted into from web page A quick and dirty fix also affected the following layout tests: editing/deleting/5026848-2.html editing/deleting/5026848-3.html moving content into table cell doesn't seem to be the point of these tests, just a side-effect editing/deleting/5115601.html mentions table cell, but point of the test doesn't seem to be table-specific - moving content into table cell seems therefore a side effect editing/unsupported-content/table-delete-001.html current result image contradicts the expectation described in the test header, fix would create intended result editing/unsupported-content/table-delete-001.html current result seems to contain extraneous br, fix would remove it editing/inserting/12882.html unexpected image diff in editing region halo (not sure why) editing/execCommand/5432254-2.html ASSERTs (placeholder br seems to get deleted/pruned) Hard to comment on this idea from such a high level view. I don't understand how EditingPosition is meant to be different from VisiblePosition. Is EditingPosition just a VisiblePosition that's also a place where you can edit? I don't understand how DOMPosition is different in intent from the current Position. I'm not sure you want the low-level class to based on RangeBoundaryPoint, since the latter has the ability to adjust in response to DOM changes, which I am not totally sure we want in this case. The basic idea would mainly be to combine PositionIterator and Position into one class EditingPosition (or just Position), focusing on performance, and to move renderer-specific code into VisualPosition (which could be (re-)named RenderedPosition for clarity). Apart from an IMHO clearer code separation this should also help improving the handling of :before/:after content renderers, which currently is buggy. DOMPosition/RangeBoundaryPoint would continue to be just the bridge to JavaScript code and not used in (most) editing code. Non-contiguous selections suck as UI, except for special cases like selecting tables by column. I don't think they are a good way to highlight find results. I don't think you want to end up with a non-contiguous selection highlighting all results when you do a find. I don't understand: Safari and Chrome both do basically exactly that (albeit in
Re: [webkit-dev] Rich Text Editing Questions, Refactoring of Position Classes
On Apr 7, 2010, at 12:11 AM, Roland Steiner wrote: Hard to comment on this idea from such a high level view. I don't understand how EditingPosition is meant to be different from VisiblePosition. Is EditingPosition just a VisiblePosition that's also a place where you can edit? I don't understand how DOMPosition is different in intent from the current Position. I'm not sure you want the low-level class to based on RangeBoundaryPoint, since the latter has the ability to adjust in response to DOM changes, which I am not totally sure we want in this case. The basic idea would mainly be to combine PositionIterator and Position into one class EditingPosition (or just Position), focusing on performance, and to move renderer-specific code into VisualPosition (which could be (re-)named RenderedPosition for clarity). Apart from an IMHO clearer code separation this should also help improving the handling of :before/:after content renderers, which currently is buggy. It's not clear to me how PositionIterator is the same concept as EditingPosition. The latter implies that it would only ever represent a position where you can edit. The former implies that it produces a sequence of positions (perhaps retaining additional state to be able to step forward/back efficiently). It also seems to me that it is useful to have a concept of a Position that is primarily optimized iteration. I'm also still not clear on the proposed relation between EditingPosition and VisiblePosition. Does every EditingPosition have an associated VisiblePosition? How about vice versa? Is the mapping one-to-one? DOMPosition/RangeBoundaryPoint would continue to be just the bridge to JavaScript code and not used in (most) editing code. Non-contiguous selections suck as UI, except for special cases like selecting tables by column. I don't think they are a good way to highlight find results. I don't think you want to end up with a non- contiguous selection highlighting all results when you do a find. I don't understand: Safari and Chrome both do basically exactly that (albeit in a somewhat souped-up fashion) - why is this capability good in the browser, but not for user scripts? Safari doesn't make this non-contiguous region a selection. It marks it with a visual highlight. Only the first hit is actually selected. This makes a big difference when doing a find in editable text - typing only overtypes the first hit, rather than replacing the non- contiguous selection. Being able to represent a non-contiguous region is interesting, but it would be UI hell to allow such a thing to actually act as the user selection, and to get copied and pasted. On Wed, Apr 7, 2010 at 3:53 AM, Justin Garcia justin.gar...@apple.com wrote: For example: divimg style=display:blockimg style=display:block/div [img1, 1] and [img2, 0] are different visually but would both be normalized to the same position under the above proposal. I think this is a great example and shows that normalizing [img, 0] to [parent-of-img, index-of-img] can probably only happen once styles and renderers are taken into account, which doesn't strictly contradict Darin's point though (?). I'm not sure how it implies that. Would you assign a real DOM position differently between the two styles? I think the real difference here is in affinity, i.e. whether the caret would be at the end of one line or the start of the next. However this doesn't affect the DOM parent and offset. Regardsm Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Rich Text Editing Questions, Refactoring of Position Classes
On Wed, Apr 7, 2010 at 4:36 PM, Maciej Stachowiak m...@apple.com wrote: It's not clear to me how PositionIterator is the same concept as EditingPosition. The latter implies that it would only ever represent a position where you can edit. The former implies that it produces a sequence of positions (perhaps retaining additional state to be able to step forward/back efficiently). It also seems to me that it is useful to have a concept of a Position that is primarily optimized iteration. Perhaps EditingPosition is not the best of names. The basic idea is that we shouldn't need 2 different classes Position and PositionIterator and convert back-and-forth between them. I'm also still not clear on the proposed relation between EditingPosition and VisiblePosition. Does every EditingPosition have an associated VisiblePosition? How about vice versa? Is the mapping one-to-one? That is a good question - it depends how we want to treat stuff like :before/:after content, list items, and such. A renderer-based VisualPosition could technically select/iterate/identify such content, but wouldn't necessarily have a corresponding Editing/DOMPosition. OTOH, an EditingPosition probably would always have an associated VisiblePosition (At least off the top of my head I can't think of a case where the user can edit stuff that isn't rendered). An EditingPosition with reflection or somesuch could in theory have more than one VisiblePosition, but I think that's getting awfully fanciful. However, the immediate idea here is more one of code separation: to put the code that operates on renderers into its separate class. Safari doesn't make this non-contiguous region a selection. It marks it with a visual highlight. Only the first hit is actually selected. This makes a big difference when doing a find in editable text - typing only overtypes the first hit, rather than replacing the non-contiguous selection. Being able to represent a non-contiguous region is interesting, but it would be UI hell to allow such a thing to actually act as the user selection, and to get copied and pasted. FWIW Firefox seems to handle it fine, but I agree that it's probably not used much in practice (apart from column selection as you mentioned). I'm thinking more of feature-completeness vs. the HTML5 spec here, and the aforementioned non-selection highlights. But whether or not to add this should be a separate discussion. On Wed, Apr 7, 2010 at 3:53 AM, Justin Garcia justin.gar...@apple.com wrote: For example: divimg style=display:blockimg style=display:block/div [img1, 1] and [img2, 0] are different visually but would both be normalized to the same position under the above proposal. I think this is a great example and shows that normalizing [img, 0] to [parent-of-img, index-of-img] can probably only happen once styles and renderers are taken into account, which doesn't strictly contradict Darin's point though (?). I'm not sure how it implies that. Would you assign a real DOM position differently between the two styles? I think the real difference here is in affinity, i.e. whether the caret would be at the end of one line or the start of the next. However this doesn't affect the DOM parent and offset. Yes, that's what I meant - the DOM Position itself should obviously not be affected by styles/CSS. This however leads me to a clarification question of my own: The [img1, 1] in Justin's example would be an invalid position, no? Do you mean that (the internal representation of) [img/block, 0] and [img/block, 1] should render the caret at different positions (i.e., the start/left side and end/right side of the block line, respectively)? Or did you mean the case of 2 images (i.e., without a real internal visual position) on different lines? Thanks, - Roland ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Rich Text Editing Questions, Refactoring of Position Classes
On Apr 7, 2010, at 1:59 AM, Roland Steiner wrote: On Wed, Apr 7, 2010 at 4:36 PM, Maciej Stachowiak m...@apple.com wrote: It's not clear to me how PositionIterator is the same concept as EditingPosition. The latter implies that it would only ever represent a position where you can edit. The former implies that it produces a sequence of positions (perhaps retaining additional state to be able to step forward/back efficiently). It also seems to me that it is useful to have a concept of a Position that is primarily optimized iteration. Perhaps EditingPosition is not the best of names. The basic idea is that we shouldn't need 2 different classes Position and PositionIterator and convert back-and-forth between them. I'm not sure I understand that goal. It's pretty normal for an iterator type to be distinct from the type of thing it iterates over. vectorT::iterator is not the same as T, even though it iterates over Ts. It is also not the same as vectorT itself. I'm not familiar with the exact state of the editing code, but that's what I think of when I hear a suggestion to combine PositionIterator and Position. I'm also not clear on where the name Editing comes from. What is it about this kind of position that's related to editing? Is it only allowed to represent positions where editing can happen? If so, then it can't be a full replacement for either Position or PositionIterator, since those are used to represent non-editable locations. If it can represent even non-editable locations, then I wonder how it differs from your proposed DOMPosition - would it be just the support for fast iteration? I'm also still not clear on the proposed relation between EditingPosition and VisiblePosition. Does every EditingPosition have an associated VisiblePosition? How about vice versa? Is the mapping one-to-one? That is a good question - it depends how we want to treat stuff like :before/:after content, list items, and such. A renderer-based VisualPosition could technically select/iterate/identify such content, but wouldn't necessarily have a corresponding Editing/ DOMPosition. OTOH, an EditingPosition probably would always have an associated VisiblePosition (At least off the top of my head I can't think of a case where the user can edit stuff that isn't rendered). An EditingPosition with reflection or somesuch could in theory have more than one VisiblePosition, but I think that's getting awfully fanciful. Could a VisiblePosition have more than one associated EditingPosition? However, the immediate idea here is more one of code separation: to put the code that operates on renderers into its separate class. I think to correctly iterate over positions where editing can happen, you need to be aware of rendering. For one thing, you want to skip stuff that is not rendered. Are you imagining that EditingPosition would be purely DOM based? Would EditingPosition or VisiblePosition be the type of object that represents a place where you can put the caret? I understand and sympathize with your attempt to clean up editing concepts, but I am not getting a sense of clean separation here. On Wed, Apr 7, 2010 at 3:53 AM, Justin Garcia justin.gar...@apple.com wrote: For example: divimg style=display:blockimg style=display:block/div [img1, 1] and [img2, 0] are different visually but would both be normalized to the same position under the above proposal. I think this is a great example and shows that normalizing [img, 0] to [parent-of-img, index-of-img] can probably only happen once styles and renderers are taken into account, which doesn't strictly contradict Darin's point though (?). I'm not sure how it implies that. Would you assign a real DOM position differently between the two styles? I think the real difference here is in affinity, i.e. whether the caret would be at the end of one line or the start of the next. However this doesn't affect the DOM parent and offset. Yes, that's what I meant - the DOM Position itself should obviously not be affected by styles/CSS. This however leads me to a clarification question of my own: The [img1, 1] in Justin's example would be an invalid position, no? Indeed; I believe he was trying to give an example of how such invalid positions might serve a meaningful purpose. Do you mean that (the internal representation of) [img/block, 0] and [img/block, 1] should render the caret at different positions (i.e., the start/left side and end/right side of the block line, respectively)? That is what happens currently, but I don't think that was Justin's main point. I think his point was that [img1, 1] renders at the end of the first line, and [img2, 0] renders at the start of the first line, even though both should normalize to a true DOM position of [div, 1] (between the two images). Or did you mean the case of 2 images (i.e., without a real internal
Re: [webkit-dev] Rich Text Editing Questions, Refactoring of Position Classes
On Wed, Apr 7, 2010 at 6:19 PM, Maciej Stachowiak m...@apple.com wrote: I'm not sure I understand that goal. It's pretty normal for an iterator type to be distinct from the type of thing it iterates over. vectorT::iterator is not the same as T, even though it iterates over Ts. It is also not the same as vectorT itself. I'm not familiar with the exact state of the editing code, but that's what I think of when I hear a suggestion to combine PositionIterator and Position. I'm also not clear on where the name Editing comes from. What is it about this kind of position that's related to editing? Is it only allowed to represent positions where editing can happen? If so, then it can't be a full replacement for either Position or PositionIterator, since those are used to represent non-editable locations. If it can represent even non-editable locations, then I wonder how it differs from your proposed DOMPosition - would it be just the support for fast iteration? Yes, Editing seems a poor choice of term, let's stay with Position. I guess my proposal (which is actually not all that radical, I think) boils down to: 1.) remove explicit support for virtual positions from Position. 2.) PositionIterator seems to be very limited in usefulness and after step 1.) there doesn't seem to be a reason why Position itself couldn't be optimized for iteration and fast access the same way as PositionIterator is, removing the need for a separate PositionIterator class. 3.) If we do step 2.), then everything that requires an explicit (node, offset) interface requires a separate class. This class already exists in the form of RangeBoundaryPoint. RangeBoundaryPoint + those additional methods are what I termed DOMPosition. Ideally, creation of a DOMPosition would only be needed at the start and end of an editing operation as input and result for JS. 4.) Bundle all code from Position and VisualPosition that operates on renderers in VisualPosition and move code from VisualPosition that doesn't operate on renderers back into Position. The resulting VisualPosition class is based on renderers rather than nodes. Re-factor editing code that queries renderers to use VisualPosition objects instead. (perhaps naming the class RenderedPosition or somesuch might be clearer). Could a VisiblePosition have more than one associated EditingPosition? Right now I can't think of a circumstance where that could be the case (it would basically mean a given renderer is associated with more than one node). I think to correctly iterate over positions where editing can happen, you need to be aware of rendering. For one thing, you want to skip stuff that is not rendered. Are you imagining that EditingPosition would be purely DOM based? Would EditingPosition or VisiblePosition be the type of object that represents a place where you can put the caret? I understand and sympathize with your attempt to clean up editing concepts, but I am not getting a sense of clean separation here. ^_^; Perhaps that's because my proposal is not ambitious enough (and discussing these exact points was what I was hoping for with my initial mails): In the initial version at least I probably would want to change as little code as possible: DOMPosition as the bridge to JS, Position continuing to be used for most of the current editing/selection logic, VisualPosition as helper class, the interface to the renderers, etc. So I guess the answer to where to store the caret position would at first (continue to) be that VisiblePosition is used to discern the place where to put it, but Position is used to actually store it (if that makes sense). However, as you point out, much of the editing logic requires information from the renderers. Ideally this would mean changing most logic to work on renderers via VisiblePosition over time, leaving Position just as somewhat of a husk between DOMPosition and VisiblePosition. This would also allow us to neatly iterate over, and select, generated content (the question being if we could actually make use of that). However, with renderers getting destroyed and rebuilt constantly I'm not sure how far this is feasible. Cheers, - Roland ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing new port: EFL
Hi, Just a simple question: - It seems that the EFL port of webkit is based on EFL/X11 api. is there plans to support other EFL backends especially directfb ? WebkitGtk is doing that with (--with-target=directfb) option. regards. Haithem. -- Say: He is God, the One and Only; God, the Eternal, Absolute; He begetteth not, nor is He begotten; And there is none like unto Him. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing new port: EFL
On Wed, Apr 7, 2010 at 3:01 AM, haithem rahmani
haithem.rahm...@gmail.com wrote:
Hi,
Just a simple question:
- It seems that the EFL port of webkit is based on EFL/X11 api.
is there plans to support other EFL backends especially directfb ?
WebkitGtk is doing that with (--with-target=directfb) option.
Yes, there are other peers interested in such support, including SDL,
FrameBuffer and DirectFB.
However we're focused on getting the patches merged into SVN first.
Any reviewer attention can help, we're almost there, just some files
pending. They are:
Pending Review:
https://bugs.webkit.org/show_bug.cgi?id=35915 Add FrameLoaderClientEfl.{cpp,h}
https://bugs.webkit.org/show_bug.cgi?id=35918 Add EditorClientEfl.{cpp,h}
https://bugs.webkit.org/show_bug.cgi?id=35932 Add ewk_view.{cpp,h}
Reviewed r-, but the answers were replied however no further review:
https://bugs.webkit.org/show_bug.cgi?id=36317 Add EFL-specific code to Widget.h
Needs GTK+ people to check it, as it will shared the same autotools system:
https://bugs.webkit.org/show_bug.cgi?id=36761 Modify the autotools build system
Simple, just need to decide where the file should go to:
https://bugs.webkit.org/show_bug.cgi?id=36405 Move
AccessibilityObjectEfl.cpp from page to accessibility
We want to get these patches in first, as they are the base for
further work. For instance, we have a huuuge number of patches to
expose various APIs that were missing, like frame loader policy,
delegates for ContextMenu, PopupMenu and so on.
BR,
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Windows Bot Wedged?
Traceback (most recent call last): File ./WebKitTools/BuildSlaveSupport/built-product-archive, line 148, in module sys.exit(main()) File ./WebKitTools/BuildSlaveSupport/built-product-archive, line 47, in main extractBuiltProduct(options.configuration, options.platform) File ./WebKitTools/BuildSlaveSupport/built-product-archive, line 124, in extractBuiltProduct shutil.rmtree(binDirectory) File /usr/lib/python2.5/shutil.py, line 174, in rmtree onerror(os.remove, fullname, sys.exc_info()) File /usr/lib/python2.5/shutil.py, line 172, in rmtree os.remove(fullname) OSError: [Errno 13] Permission denied: '/home/buildbot/slave/win-release-tests/build/WebKitBuild/bin/DumpRenderTree.exe' If someone with access could kick it, that would be great. :) -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Windows Bot Wedged?
I'll take care of it, thanks for the heads up. Brian On Apr 7, 2010, at 9:20 PM, Eric Seidel wrote: Traceback (most recent call last): File ./WebKitTools/BuildSlaveSupport/built-product-archive, line 148, in module sys.exit(main()) File ./WebKitTools/BuildSlaveSupport/built-product-archive, line 47, in main extractBuiltProduct(options.configuration, options.platform) File ./WebKitTools/BuildSlaveSupport/built-product-archive, line 124, in extractBuiltProduct shutil.rmtree(binDirectory) File /usr/lib/python2.5/shutil.py, line 174, in rmtree onerror(os.remove, fullname, sys.exc_info()) File /usr/lib/python2.5/shutil.py, line 172, in rmtree os.remove(fullname) OSError: [Errno 13] Permission denied: '/home/buildbot/slave/win-release-tests/build/WebKitBuild/bin/DumpRenderTree.exe' If someone with access could kick it, that would be great. :) -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Windows Bot Wedged?
Should be fixed now. Brian On Apr 7, 2010, at 9:22 PM, Brian Weinstein wrote: I'll take care of it, thanks for the heads up. Brian On Apr 7, 2010, at 9:20 PM, Eric Seidel wrote: Traceback (most recent call last): File ./WebKitTools/BuildSlaveSupport/built-product-archive, line 148, in module sys.exit(main()) File ./WebKitTools/BuildSlaveSupport/built-product-archive, line 47, in main extractBuiltProduct(options.configuration, options.platform) File ./WebKitTools/BuildSlaveSupport/built-product-archive, line 124, in extractBuiltProduct shutil.rmtree(binDirectory) File /usr/lib/python2.5/shutil.py, line 174, in rmtree onerror(os.remove, fullname, sys.exc_info()) File /usr/lib/python2.5/shutil.py, line 172, in rmtree os.remove(fullname) OSError: [Errno 13] Permission denied: '/home/buildbot/slave/win-release-tests/build/WebKitBuild/bin/DumpRenderTree.exe' If someone with access could kick it, that would be great. :) -eric ___ 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
