[webkit-dev] Progressing on the Android port
Hi WebKit-dev folks, in the spirit of the mails describing new features I would like to talk about my intention regarding the Android port. == Aim == I want to build WebKit trunk for Android and use it on a phone. This means I want to have build-webkit integration, will host a buildbot, will work towards having LayoutTests for Android. == Requirements == I am going to use the Native Development Kit (NDK), there is also the requirement of having Skia and one of the two networking libraries. At this point I am not sure if I want to go the Chromium way and pull the code into the repository with a script or require these libraries to be built. I have a preference for the later right now. == How == I want to use CMake as the buildsystem. The main reason is that it is already used by other ports and the CMake community provides an easy way to use the Android NDK. My aim is to use the existing SKIA (as used by Chromium/Linux) as there seems to be a great overlap between Android and Chromium/Linux, I will also try to merge existing Android files for other parts of the system. == Conflict(s) == This port is not supported by Google/Android, this might or might not cause problems. It all depends on how compatible my aim is with the plans of the Android Unit. Another issue might come from the fact that I want to build it with the Android NDK, instead of having WebKit built as part of the Android system. I hope Google will be able to use CMake to generate a Android.mk. == When == I will try to spend one day a week on it. So it might take a while. cheers holger ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature - MHTML support
On May 2, 2011, at 6:03 PM, Eric Seidel wrote: MHTML support was definitely discussed at length back in the early days of Safari Windows development in webkit.org. Maybe that desire has gone away since then. I feel very out-of-touch with current Safari-on-Windows needs. We've had requests for MHTML support on Windows and on Mac. I don't think the requests have been terribly frequent. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Progressing on the Android port
Hi Holger Freyther, On Thu, May 12, 2011 at 7:08 AM, Holger Freyther ze...@selfish.org wrote: == How == I want to use CMake as the buildsystem. The main reason is that it is already used by other ports and the CMake community provides an easy way to use the Android NDK. My aim is to use the existing SKIA (as used by Chromium/Linux) as there seems to be a great overlap between Android and Chromium/Linux, I will also try to merge existing Android files for other parts of the system. I'm glad to hear you will use CMake as the build system. Take a look on the email I sent yesterday porting GTK to CMake, maybe it will help you. Since Android and Chromium/Linux have overlaps, do you think it'd be easy to build the Chromium port as well? Regards, Lucas De Marchi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Why is gtest in the Source directory?
Is gtest required to build any of the WebKit ports? If not, can it be moved out of Source and into Tools? Thanks, —Dan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Unifying the build systems
On Wed, May 11, 2011 at 9:31 PM, Lucas De Marchi lucas.demar...@profusion.mobi wrote: This implementation still lacks some parts (these are the biggest ones I remember from top of my head, there might be others): - There's no option to enable WebKit2, webgl and webaudio; - It always uses GTK2 - GIR files are not generated - Unit test files are not compiled Cool work! Along with these requirements, a replacement build system would also need: 1. make dist and make distcheck functionality 2. The ability to generate GTK+-style documentation for our APIs --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why is gtest in the Source directory?
It sounds like you have a helpful mental mapping for what belongs in each directory that we haven't written anywhere. Perhaps you could write it down and send it to webkit-dev so that we can make it a common model. It feels like a related topic is why are the unit tests under Tools as opposed to being by the files that they test. Being by the files they tests would make them easier to find and change as needed. (For an example of where this is done, see http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common where there is file.py and file_unittest.py) dave On Thu, May 12, 2011 at 8:36 AM, Dan Bernstein m...@apple.com wrote: Is gtest required to build any of the WebKit ports? If not, can it be moved out of Source and into Tools? Thanks, —Dan ___ 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] Why is gtest in the Source directory?
I think more important issue to consider is should WebKit unit-tests (TestWebKitAPI) live under Tools. Unit-tests evolve with the product and an organic part of it - it doesn't feel that they constitute a tool. Three possible locations come to mind: - ./Tests - separate top-level directory, sibling to Source and LayoutTests - ./Source/Test - separate directory, but under Source to emphasize that tests are part of the source code - Scattered around by the files that tests test, as David suggests. In terms of gtest directory placement, I think it is nice to have all third-party libraries live in the same place. What do people think? Kind regards, Dmitry On Thu, May 12, 2011 at 9:38 AM, David Levin le...@chromium.org wrote: It sounds like you have a helpful mental mapping for what belongs in each directory that we haven't written anywhere. Perhaps you could write it down and send it to webkit-dev so that we can make it a common model. It feels like a related topic is why are the unit tests under Tools as opposed to being by the files that they test. Being by the files they tests would make them easier to find and change as needed. (For an example of where this is done, see http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common where there is file.py and file_unittest.py) dave On Thu, May 12, 2011 at 8:36 AM, Dan Bernstein m...@apple.com wrote: Is gtest required to build any of the WebKit ports? If not, can it be moved out of Source and into Tools? Thanks, —Dan ___ 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] Why is gtest in the Source directory?
Here's a straw-man proposal: Tests/ Layout/ # Would be nice to have a better name since these test much more than Layout Performance/ Unit/ Manual/ Source/ JavaScriptCore/ WebCore/ WebKit/ ThirdParty/ ANGLE/ Tools/ WebKitTestRunner/ MiniBrowser/ Scripts/ In this organization, gtest probably doesn't belong in Source because it's not a dependency of WebKit. It probably belongs somewhere in Tests. Maybe inside the Unit directory somewhere? Adam On Thu, May 12, 2011 at 10:24 AM, Dmitry Lomov dslo...@google.com wrote: I think more important issue to consider is should WebKit unit-tests (TestWebKitAPI) live under Tools. Unit-tests evolve with the product and an organic part of it - it doesn't feel that they constitute a tool. Three possible locations come to mind: - ./Tests - separate top-level directory, sibling to Source and LayoutTests - ./Source/Test - separate directory, but under Source to emphasize that tests are part of the source code - Scattered around by the files that tests test, as David suggests. In terms of gtest directory placement, I think it is nice to have all third-party libraries live in the same place. What do people think? Kind regards, Dmitry On Thu, May 12, 2011 at 9:38 AM, David Levin le...@chromium.org wrote: It sounds like you have a helpful mental mapping for what belongs in each directory that we haven't written anywhere. Perhaps you could write it down and send it to webkit-dev so that we can make it a common model. It feels like a related topic is why are the unit tests under Tools as opposed to being by the files that they test. Being by the files they tests would make them easier to find and change as needed. (For an example of where this is done, see http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common where there is file.py and file_unittest.py) dave On Thu, May 12, 2011 at 8:36 AM, Dan Bernstein m...@apple.com wrote: Is gtest required to build any of the WebKit ports? If not, can it be moved out of Source and into Tools? Thanks, —Dan ___ 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] Where should unittests live? WAS: Why is gtest in the Source directory?
Changing the subject to let the original thread remain on topic of where gtest itself should live. Having the unittest file live next to the file it's testing has been great on projects I've worked on (e.g. webkitpy). It makes it straightforward to identify if a give file has unittests and to add to them. Unless this would cause problems for anyone's build systems, I'd vote for this. If they lived in a separate tree, I'd want the tree to match the Source tree in structure so that it's clear where the tests for a file live, but that feels like a lot of unnecessary overhead. On Thu, May 12, 2011 at 10:24 AM, Dmitry Lomov dslo...@google.com wrote: I think more important issue to consider is should WebKit unit-tests (TestWebKitAPI) live under Tools. Unit-tests evolve with the product and an organic part of it - it doesn't feel that they constitute a tool. Three possible locations come to mind: - ./Tests - separate top-level directory, sibling to Source and LayoutTests - ./Source/Test - separate directory, but under Source to emphasize that tests are part of the source code - Scattered around by the files that tests test, as David suggests. In terms of gtest directory placement, I think it is nice to have all third-party libraries live in the same place. What do people think? Kind regards, Dmitry On Thu, May 12, 2011 at 9:38 AM, David Levin le...@chromium.org wrote: It sounds like you have a helpful mental mapping for what belongs in each directory that we haven't written anywhere. Perhaps you could write it down and send it to webkit-dev so that we can make it a common model. It feels like a related topic is why are the unit tests under Tools as opposed to being by the files that they test. Being by the files they tests would make them easier to find and change as needed. (For an example of where this is done, see http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common where there is file.py and file_unittest.py) dave On Thu, May 12, 2011 at 8:36 AM, Dan Bernstein m...@apple.com wrote: Is gtest required to build any of the WebKit ports? If not, can it be moved out of Source and into Tools? Thanks, —Dan ___ 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] crash during plugin unload
Hello, I am seeing a crash in the android browser when unloading an NPAPI plugin I am developing. I do not see the problem in chrome, so am wondering if anyone can help me sort out what's different between the two. The test web page is passing a JS object to the plugin, which calls NPN_SetProperty on the JS object with a couple of plugin created objects. When the object element is removed as the page is getting cleaned up, the browser does not release the plugin created object until after it unloads the plugin. At that point the code for deallocate doesn't exist anymore, so the browser crashes. Looking into the code a bit, I see that plugin created objects are registered with an owner object, and that cleanup will remove the sub-objects of the owner (this is in the V8 binding). However I also see that in WebCore/bindings/v8/NPV8Object.cpp, the owner for set property is object-rootObject-frame()-script()-windowScriptNPObject(): the window object, not the object. So it looks as though it will not be considered a sub-object of object, and therefore not be released before the plugin is unloaded. Is this a bug, or am I missing something more fundamental here? Also, if this is more appropriate to one of the android lists, please let me know. This looks like common code so I'm starting with this list. Other info: I've verified that the referenceCount field is correct on the plugin created object. I also see the problem with other plugin-created objects having window as an owner and not getting released before the plugin is unloaded. Thanks, -Todd ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why is gtest in the Source directory?
On Thu, May 12, 2011 at 10:36 AM, Adam Barth aba...@webkit.org wrote: Here's a straw-man proposal: Tests/ -- All testing code. Do test harnesses go here too? Layout/ # Would be nice to have a better name since these test much more than Layout DumpRenderTreeTests? Integration? AutomatedHtmlTests? Performance/ Unit/ with a directory structure that mirrors Source for the tests Manual/ Source/ -- Only the source code necessary for building WebKit. JavaScriptCore/ WebCore/ WebKit/ ThirdParty/ ANGLE/ Tools/ WebKitTestRunner/ MiniBrowser/ Scripts/ In this organization, gtest probably doesn't belong in Source because it's not a dependency of WebKit. I agree but I felt like it lacked explicit definition, so I added some. It probably belongs somewhere in Tests. Maybe inside the Unit directory somewhere? I think so. I wonder why we wouldn't put all tests related code under Tests. For example WebKitTestRunner, DumpRenderTree, CSSTestSuiteHarness seem to fit in that category and be similar in some ways to gtest in that they are the test harness. Adam On Thu, May 12, 2011 at 10:24 AM, Dmitry Lomov dslo...@google.com wrote: I think more important issue to consider is should WebKit unit-tests (TestWebKitAPI) live under Tools. Unit-tests evolve with the product and an organic part of it - it doesn't feel that they constitute a tool. Three possible locations come to mind: - ./Tests - separate top-level directory, sibling to Source and LayoutTests - ./Source/Test - separate directory, but under Source to emphasize that tests are part of the source code - Scattered around by the files that tests test, as David suggests. In terms of gtest directory placement, I think it is nice to have all third-party libraries live in the same place. What do people think? Kind regards, Dmitry On Thu, May 12, 2011 at 9:38 AM, David Levin le...@chromium.org wrote: It sounds like you have a helpful mental mapping for what belongs in each directory that we haven't written anywhere. Perhaps you could write it down and send it to webkit-dev so that we can make it a common model. It feels like a related topic is why are the unit tests under Tools as opposed to being by the files that they test. Being by the files they tests would make them easier to find and change as needed. (For an example of where this is done, see http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/commonwhere there is file.py and file_unittest.py) dave On Thu, May 12, 2011 at 8:36 AM, Dan Bernstein m...@apple.com wrote: Is gtest required to build any of the WebKit ports? If not, can it be moved out of Source and into Tools? Thanks, —Dan ___ 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] Why is gtest in the Source directory?
Functional? Regards, Tim. On Thu, May 12, 2011 at 10:48 PM, Darin Adler da...@apple.com wrote: On May 12, 2011, at 11:33 AM, David Levin wrote: Layout/ # Would be nice to have a better name since these test much more than Layout DumpRenderTreeTests? Integration? AutomatedHtmlTests? Here are some characteristics of these tests that may help us name the directory: 1) This is the primary suite of WebKit tests. 2) These tests are all automated. 3) These tests all include an expected result (broadly including future addition of reftests). 4) These tests are regression tests; most are designed to catch any changes in behavior, not just detect failure. 5) These tests consist of HTML or SVG markup, with CSS and JavaScript, much like webpages in the wild. 6) Most of these tests can also be run by opening them in a web browser. 7) Most of these tests are designed to test end-to-end, although some are more like unit tests. I don’t think they should be named after DumpRenderTree because that name is itself a misnomer. I think that (7) above does fit with the name Integration, but that name still doesn’t work so well for me. Despite (5) above I don’t love the idea of having HTML in the name when we can accommodate SVG tests too. -- Darin ___ 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] Why is gtest in the Source directory?
On May 12, 2011, at 11:48 AM, Darin Adler wrote: On May 12, 2011, at 11:33 AM, David Levin wrote: Layout/ # Would be nice to have a better name since these test much more than Layout DumpRenderTreeTests? Integration? AutomatedHtmlTests? Here are some characteristics of these tests that may help us name the directory: 1) This is the primary suite of WebKit tests. 2) These tests are all automated. 3) These tests all include an expected result (broadly including future addition of reftests). 4) These tests are regression tests; most are designed to catch any changes in behavior, not just detect failure. 5) These tests consist of HTML or SVG markup, with CSS and JavaScript, much like webpages in the wild. 6) Most of these tests can also be run by opening them in a web browser. 7) Most of these tests are designed to test end-to-end, although some are more like unit tests. I don’t think they should be named after DumpRenderTree because that name is itself a misnomer. I think that (7) above does fit with the name Integration, but that name still doesn’t work so well for me. Despite (5) above I don’t love the idea of having HTML in the name when we can accommodate SVG tests too. What about just Web, Engine or WebPages? If SVG complicates the naming issue, maybe it could be moved to its own top level directory? That would avoid any confusion over where one would expect to find the SVG tests. Kevin -- Darin ___ 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] Why is gtest in the Source directory?
On Thu, May 12, 2011 at 11:33 AM, David Levin le...@chromium.org wrote: On Thu, May 12, 2011 at 10:36 AM, Adam Barth aba...@webkit.org wrote: Here's a straw-man proposal: Tests/ -- All testing code. Do test harnesses go here too? Layout/ # Would be nice to have a better name since these test much more than Layout DumpRenderTreeTests? Integration? AutomatedHtmlTests? Performance/ Unit/ with a directory structure that mirrors Source for the tests Manual/ Source/ -- Only the source code necessary for building WebKit. JavaScriptCore/ WebCore/ WebKit/ ThirdParty/ ANGLE/ Tools/ WebKitTestRunner/ MiniBrowser/ Scripts/ In this organization, gtest probably doesn't belong in Source because it's not a dependency of WebKit. I agree but I felt like it lacked explicit definition, so I added some. It probably belongs somewhere in Tests. Maybe inside the Unit directory somewhere? I think so. I wonder why we wouldn't put all tests related code under Tests. For example WebKitTestRunner, DumpRenderTree, CSSTestSuiteHarness seem to fit in that category and be similar in some ways to gtest in that they are the test harness. Dmitry Lomov pointed out to me that DRT is a tool on its own. Now, I see a reasonable distinction here. In short, test harnesses are tools. oth, gtest is part of the test code itself. Adam On Thu, May 12, 2011 at 10:24 AM, Dmitry Lomov dslo...@google.com wrote: I think more important issue to consider is should WebKit unit-tests (TestWebKitAPI) live under Tools. Unit-tests evolve with the product and an organic part of it - it doesn't feel that they constitute a tool. Three possible locations come to mind: - ./Tests - separate top-level directory, sibling to Source and LayoutTests - ./Source/Test - separate directory, but under Source to emphasize that tests are part of the source code - Scattered around by the files that tests test, as David suggests. In terms of gtest directory placement, I think it is nice to have all third-party libraries live in the same place. What do people think? Kind regards, Dmitry On Thu, May 12, 2011 at 9:38 AM, David Levin le...@chromium.org wrote: It sounds like you have a helpful mental mapping for what belongs in each directory that we haven't written anywhere. Perhaps you could write it down and send it to webkit-dev so that we can make it a common model. It feels like a related topic is why are the unit tests under Tools as opposed to being by the files that they test. Being by the files they tests would make them easier to find and change as needed. (For an example of where this is done, see http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/commonwhere there is file.py and file_unittest.py) dave On Thu, May 12, 2011 at 8:36 AM, Dan Bernstein m...@apple.com wrote: Is gtest required to build any of the WebKit ports? If not, can it be moved out of Source and into Tools? Thanks, —Dan ___ 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] Question on Inline element
Hi All, I was trying to develop my expertise by looking at some of the open issues I was looking intohttps://bugs.webkit.org/show_bug.cgi?id=22764.https://bugs.webkit.org/show_bug.cgi?id=22764(Issue with Windows build). We have done a preliminarily analysis I want to get little help so that we can proceed even further. I have attached the source html also the snapshot so that we can see the issue. The problem is because of the following line pimg src=feed.png alt=RSS width=17 border=0 height=17 align=leftSubscribe/p The paragraph element has all children inline (even though the image is non-inline, but because it is a float/positioned object so it remains inline element), as a result while doing the layout for the paragraph element, it is only doing the layout for inline children. Following code in RenderBlock::layoutBlock() if (childrenInline()) layoutInlineChildren(relayoutChildren, repaintLogicalTop, repaintLogicalBottom); ==Control goes here else layoutBlockChildren(relayoutChildren, maxFloatLogicalBottom); And then it goes to RenderBlock::createLineBoxesFromBidiRuns() where it is only considering all the textual attributes (mainly font height which is 12 pixel), not considering the image height which is greater than the text height. So my question is - Can a paragraph element contain an image element= the html spec does not say NO. - If we make the image element neither float/nor positioned, it creates an anomynous block everything is rendered properly. But I am not sure whether that is the right approach. Can any one please throw some light here help us out. Thanks. Some text here Subscribe attachment: feed.pngattachment: left_col_box_bcorners.jpgattachment: Bugzilla_WebKit_Issue_22764.JPG___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
