Re: [webkit-dev] WebKit gtk saving Full Web Page Content to Image PNG/XBM
Hi Maybe you should be asking this in webkit-help. Anyways, You can try using a cairo ( i think ). Basically, you can create an offscreen bitmap and make webview draw on to it. Then serialize ( or save ) it in any image format. Thanks Regards Niilesh On Sat, Apr 17, 2010 at 11:28 AM, satya kishan tskis...@yahoo.com wrote: WebKit Team, I am using the WebKit-gtk release r55959 I need to Save the Complete Web Page as Image PNG or any format. Is there any API to do this and on the Platform Linux Please Help in this regards. thanks satya ___ 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] Regarding malicious javascript detection
Hi
I have one doubt about javascript that does malicious things. Consider
following javascript.
script language=JavaScript
var n=unescape(%u9090);
var
s=unescape(%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u%u);
for(var i=0;i64;i++){
n=n+n;
document.write('scriptthrow n+s;/scr'+'ipt');
}
/script
Above code causes exception and there by causing crash. Though Chrome doesnt
close. I am not sure what this scrpt does, but i think this is something to
do with 'throw' in JavaScript.
Maybe something to do with overflow.
My doubt is,
Is there any kind of handling done for above scenario which are potential
for hacking ?
I have Chrome 4.1.249.1045 (42898) on which above script crashes Chrome
page.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Regarding malicious javascript detection
Date: Sat, 17 Apr 2010 15:19:16 +0530 From: To: webkit-h...@lists.webkit.org; webkit-dev@lists.webkit.org Subject: [webkit-dev] Regarding malicious javascript detection Hi I have one doubt about javascript that does malicious things. Consider following javascript. Just one? LOL. I would mention, esp in regards to things like rendering on UI thread, any arbitrary code can do anything without reading the mind of the author ( malicious or stupid intent ) , and needs to be executed with no assumptions about its goodness in any sense and in some way it can't kill the app through programmatic means or simple resource depltion ( programmatic including execution of data or calling some OS exit thing, resource depltion being stack overflow, cpu etc) . Having stated the obvious, I would ask if there is a tutorial or links in the code to references on generally how JS is implemented- leaving through code it looked like there was a bunch of stuff about a bytecode compiler etc. Interpretted byte code languages like java usually can be made much more safe than native code executors but there are still issues with resource wasters that kill entire app or machine ( you get those pop ups about a script is causing computer to run slowly, do you want to terminate it?). Memory waste in heap or I guess even stack, depletion of CPU, IO or even graphics resources ( I swear sometimes my java applets had problems due to underlying native grappics resource leaks that sometimes got reported as OutOfMemoryError) and other resource mis-allocations can cause lots of performance issues before a crach or lock up occurs. You might want to consider these security issues in a larger context. Above code causes exception and there by causing crash. Though Chrome doesnt close. I am not sure what this scrpt does, but i think this is something to do with 'throw' in JavaScript. Maybe something to do with overflow. My doubt is, Is there any kind of handling done for above scenario which are potential for hacking ? I have Chrome 4.1.249.1045 (42898) áon which above script crashes Chrome page. _ The New Busy is not the old busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_3 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebKitGTK+ debug buildbots crash dumps
Hi, we have installed a crash dumps analysis to the WebKitGTK+ debug bots, this way it is easier to check what has failed when a test crashes inside the bots. It has already gave us good information about flacky tests root causes. You can check it here: http://webkit-bots.igalia.com/ We are planning to add the name of the test failing to the information. Maybe it is a good idea to add this kind of service to the buildbot page someway? br ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit meeting notes] build systems
Hi Maciej, On Apr 16, 2010, at 3:34 PM, Maciej Stachowiak wrote: On Apr 16, 2010, at 8:09 AM, Nikolas Zimmermann wrote: Am 16.04.2010 um 16:44 schrieb Adam Treat: I am very skeptical that it is feasible to write a gyp generator that would output QMake files. There is a log of magic in those QMake files. My sense is that it would not be trivial by any means. Plus, I don't like the idea of a meta-meta generators. Seems way to mickey- mouse to me. Agreed to a certain degree. Using gyp/whatever to generate qmake files, to generate Makefile/Xcode files etc seems akward to me as well. What we really need to resolve is adding/removing files from compilation, that's the most common task that has to be done in 5+ build systems at the moment. Besides adding, removing and renaming, the other thing that's really hard is adding a new generated source rule. Although this is not needed as frequently, I think anyone adding a new code generator script that has to work across all WebKit ports would have a hellish time of it right now. If I had to do it myself, I would just skip any ports that don't use DerivedSources.make. So I have a new proposal: 1) Maintain a list of headers/source files to be compiled for ALL platforms (ie. dom/Node.cpp, etc..) 2) Keep all existing Makefile.am, WebCore.pro etc files as templates, ie. WebCore.pro.template, with a special variable somewhere marking the $$HEADER_LIST$$ and the $$SOURCE_LIST$$ 3) Use a script that generates individual build files (eg. WebCore.pro) from WebCore.pro.template, it only needs to insert the file list with the correct syntax in the correct places 4) Keep all platform specific files to be compiled in the individual build system files (eg. WebCore.pro.template) I think we'll never find a consensus on a single build system, there are too many different needs. I only care about the most repetitive work in order to keep the build system up2date: adding/removing cross-platform files. I think the proposal above does not handle the derived sources problem. It also doesn't handle files that are shared between multiple ports but not all ports. It also doesn't provide project files that are directly usable by IDEs, on platforms where that is the standard way to do development. Converting, say, a JSON list of files to some XML-based output format would not be difficult at all (and I believe we can automatically convert the XCode project files from binary to plist and back, though IIRC there might be some UUID handling issues to consider), so we could patch the IDE files much like we patch the other ports. As for the other cases, such as additions / removals of things shared by multiple ports and the derived sources problem (that one probably would indeed need some 'template' to insert into project files), I think these could be added over time if we feel it'd bring a large benefit, but I think even just covering the common case of cross-platform source file maintenance is already a huge win for the project. I maintained Bakefile projects for years, and I'd say 80-90% of the time when a change broke my build, it was one of these common source file additions / removals. And it usually happened several times every week. I personally think the way to look at it is to start by solving the simple stuff that could be solved quickly, as in my experience that makes it far more likely to actually get done. If, say, gyp - Gtk / Qt / MSVC (/ XCode?) build file lists could be done in a weekend of hacking and some devs are interested in working on it, why not? Once we start solving problems like that, I suspect we end up with something closer in complexity to Gyp or CMake. True, but I think the real problem that we're not addressing in this discussion is that different ports have different sets of requirements, meaning their own evaluation process would lead them to choose different tools. If we want a 'one size fits all' build system, the first step is getting each port to come together and consolidate the requirements, and there will most likely need to be some compromises involved as some ports may have to agree to move to a tool that's not really as well suited for their project as the one they're using now. For example, a primary reason tools like Gyp and Bakefile exist is that for some people, lack of a 100% native IDE-based build system is a deal breaker. For others, like myself, I want low maintenance, completely cross-platform, highly automated and highly scriptable, which are actually features the IDE projects don't fare very well in. So one man's feature is another man's drawback. There are also factors besides features that are important as well. I think it's also important to remember that from each port's perspective, one potentially big factor in build system choice is also making users comfortable with contributing. For GTK, for
Re: [webkit-dev] [webkit meeting notes] build systems
2010/4/17 Kevin Ollivier kev...@theolliviers.com Hi Maciej, On Apr 16, 2010, at 3:34 PM, Maciej Stachowiak wrote: On Apr 16, 2010, at 8:09 AM, Nikolas Zimmermann wrote: Am 16.04.2010 um 16:44 schrieb Adam Treat: I am very skeptical that it is feasible to write a gyp generator that would output QMake files. There is a log of magic in those QMake files. My sense is that it would not be trivial by any means. Plus, I don't like the idea of a meta-meta generators. Seems way to mickey- mouse to me. Agreed to a certain degree. Using gyp/whatever to generate qmake files, to generate Makefile/Xcode files etc seems akward to me as well. What we really need to resolve is adding/removing files from compilation, that's the most common task that has to be done in 5+ build systems at the moment. Besides adding, removing and renaming, the other thing that's really hard is adding a new generated source rule. Although this is not needed as frequently, I think anyone adding a new code generator script that has to work across all WebKit ports would have a hellish time of it right now. If I had to do it myself, I would just skip any ports that don't use DerivedSources.make. So I have a new proposal: 1) Maintain a list of headers/source files to be compiled for ALL platforms (ie. dom/Node.cpp, etc..) 2) Keep all existing Makefile.am, WebCore.pro etc files as templates, ie. WebCore.pro.template, with a special variable somewhere marking the $$HEADER_LIST$$ and the $$SOURCE_LIST$$ 3) Use a script that generates individual build files (eg. WebCore.pro) from WebCore.pro.template, it only needs to insert the file list with the correct syntax in the correct places 4) Keep all platform specific files to be compiled in the individual build system files (eg. WebCore.pro.template) I think we'll never find a consensus on a single build system, there are too many different needs. I only care about the most repetitive work in order to keep the build system up2date: adding/removing cross-platform files. I think the proposal above does not handle the derived sources problem. It also doesn't handle files that are shared between multiple ports but not all ports. It also doesn't provide project files that are directly usable by IDEs, on platforms where that is the standard way to do development. Converting, say, a JSON list of files to some XML-based output format would not be difficult at all (and I Like this? http://trac.webkit.org/browser/trunk/WebCore/WebCore.gypi - It is currently not JSON compliant. It's in fact a python file but that can be fixed: s/'//g and removing the extra commas *should* be sufficient. - It is currently chromium specific, that's what I meant by de-chromification of the gyp files. It's mainly adding more stuff and fixing the regexp if I'm not mistaken. I don't mind if it doesn't become the golden file, the goal is just to hopefully reduce the number of build system, nothing more. believe we can automatically convert the XCode project files from binary to plist and back, though IIRC there might be some UUID handling issues to consider), so we could patch the IDE files much like we patch the other ports. As for the other cases, such as additions / removals of things shared by multiple ports and the derived sources problem (that one probably would indeed need some 'template' to insert into project files), I think these could be added over time if we feel it'd bring a large benefit, but I think even just covering the common case of cross-platform source file maintenance is already a huge win for the project. I maintained Bakefile projects for years, and I'd say 80-90% of the time when a change broke my build, it was one of these common source file additions / removals. And it usually happened several times every week. I personally think the way to look at it is to start by solving the simple stuff that could be solved quickly, as in my experience that makes it far more likely to actually get done. If, say, gyp - Gtk / Qt / MSVC (/ XCode?) build file lists could be done in a weekend of hacking and some devs are interested in working on it, why not? Once we start solving problems like that, I suspect we end up with something closer in complexity to Gyp or CMake. True, but I think the real problem that we're not addressing in this discussion is that different ports have different sets of requirements, meaning their own evaluation process would lead them to choose different tools. If we want a 'one size fits all' build system, the first step is getting each port to come together and I don't think anyone wants that. It's just too involved. consolidate the requirements, and there will most likely need to be some compromises involved as some ports may have to agree to move to a tool that's not really as well suited for their project as the one they're using now. For example, a
Re: [webkit-dev] Loader diagram from yesterday's session
I took the liberty of cleaning up this diagram in sketchy: http://webblaze.org/abarth/webkit-loader.html If folks find this diagram useful, we can add it to the web site. Adam On Thu, Apr 15, 2010 at 12:06 AM, Jeremy Orlow jor...@chromium.org wrote: Several people asked me for a copy of this picture so I figured I'd just send it to the whole list. (P.S. Thanks Maciej and Dr. Barth for leading the session!) J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit meeting notes] build systems
On Apr 17, 2010, at 11:11 AM, Kevin Ollivier wrote: True, but I think the real problem that we're not addressing in this discussion is that different ports have different sets of requirements, meaning their own evaluation process would lead them to choose different tools. If we want a 'one size fits all' build system, the first step is getting each port to come together and consolidate the requirements, and there will most likely need to be some compromises involved as some ports may have to agree to move to a tool that's not really as well suited for their project as the one they're using now. It's true that different ports have different requirements. So far, this has resulted in every port choosing a different build system. While in some ways this may be convenient for individual ports, it creates negative externalities for the project as a whole. That being said, we're not trying to convert to one true build system right now, merely seeing if we can reduce the number by having more ports share a build system. We're even considering changing the build system for Apple's ports (in fact the Apple Windows port may be one of the first experiments). For example, a primary reason tools like Gyp and Bakefile exist is that for some people, lack of a 100% native IDE-based build system is a deal breaker. For others, like myself, I want low maintenance, completely cross-platform, highly automated and highly scriptable, which are actually features the IDE projects don't fare very well in. So one man's feature is another man's drawback. There are also factors besides features that are important as well. I think it's also important to remember that from each port's perspective, one potentially big factor in build system choice is also making users comfortable with contributing. For GTK, for example, that may mean that using autotools, the build system most likely to be familiar to potential contributors, is in part a way of making contributing a little less intimidating on a big project like WebKit. Similar with qmake, XCode, etc. I think that a big part of build system decision making is based not necessarily around features, but around being in the developers' comfort zones. So my gut impression is that it's going to be very difficult to find an existing tool that solves all the issues like this for most / all ports in a way that makes everyone happy. As the saying goes, sometimes the perfect is indeed the enemy of the good. I personally think a quick and simple solution along the lines of what Nikolas and I were talking about maybe the only short term improvement that is viable. Everything else is looking more long- term, and requires both a lot of effort and a lot of collaboration among ports. To the point that, as a practical matter, I'm not sure if the system would save more time than it would take to develop. That's not to say such a system won't be developed, but absent some sponsorship of the project or some highly motivated hackers, I don't know how we plan on getting there. I just think this subject has come up numerous times, and each time the discussion ended without any improvements being made, so I worry that so long as we wait for the perfect system to come along, we're not going to build the good system that can make life better today. I would put that the other way around. Gyp exists today and knows how to generate an Xcode project. The templating solution that can generate an Xcode project while seeming less intrusive to Bakefile and Automake users is completely hypothetical. Anyone who wants to is welcome to try to code it, but my expectation going in is that it would evolve to be as complex as Gyp. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Loader diagram from yesterday's session
On Apr 17, 2010, at 5:22 PM, Adam Barth wrote: I took the liberty of cleaning up this diagram in sketchy: http://webblaze.org/abarth/webkit-loader.html If folks find this diagram useful, we can add it to the web site. Looks good, throw it on the wiki maybe? (You can include images on a wiki page by making them attachments first, that's what I did for the diagrams on http://trac.webkit.org/wiki/WebKit2). Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit meeting notes] build systems
Hi Marc-Antoine, On Apr 17, 2010, at 11:26 AM, Marc-Antoine Ruel wrote: 2010/4/17 Kevin Ollivier kev...@theolliviers.com Hi Maciej, On Apr 16, 2010, at 3:34 PM, Maciej Stachowiak wrote: On Apr 16, 2010, at 8:09 AM, Nikolas Zimmermann wrote: Am 16.04.2010 um 16:44 schrieb Adam Treat: I am very skeptical that it is feasible to write a gyp generator that would output QMake files. There is a log of magic in those QMake files. My sense is that it would not be trivial by any means. Plus, I don't like the idea of a meta-meta generators. Seems way to mickey- mouse to me. Agreed to a certain degree. Using gyp/whatever to generate qmake files, to generate Makefile/Xcode files etc seems akward to me as well. What we really need to resolve is adding/removing files from compilation, that's the most common task that has to be done in 5+ build systems at the moment. Besides adding, removing and renaming, the other thing that's really hard is adding a new generated source rule. Although this is not needed as frequently, I think anyone adding a new code generator script that has to work across all WebKit ports would have a hellish time of it right now. If I had to do it myself, I would just skip any ports that don't use DerivedSources.make. So I have a new proposal: 1) Maintain a list of headers/source files to be compiled for ALL platforms (ie. dom/Node.cpp, etc..) 2) Keep all existing Makefile.am, WebCore.pro etc files as templates, ie. WebCore.pro.template, with a special variable somewhere marking the $$HEADER_LIST$$ and the $$SOURCE_LIST$$ 3) Use a script that generates individual build files (eg. WebCore.pro) from WebCore.pro.template, it only needs to insert the file list with the correct syntax in the correct places 4) Keep all platform specific files to be compiled in the individual build system files (eg. WebCore.pro.template) I think we'll never find a consensus on a single build system, there are too many different needs. I only care about the most repetitive work in order to keep the build system up2date: adding/removing cross-platform files. I think the proposal above does not handle the derived sources problem. It also doesn't handle files that are shared between multiple ports but not all ports. It also doesn't provide project files that are directly usable by IDEs, on platforms where that is the standard way to do development. Converting, say, a JSON list of files to some XML-based output format would not be difficult at all (and I Like this? http://trac.webkit.org/browser/trunk/WebCore/WebCore.gypi - It is currently not JSON compliant. It's in fact a python file but that can be fixed: s/'//g and removing the extra commas should be sufficient. - It is currently chromium specific, that's what I meant by de-chromification of the gyp files. It's mainly adding more stuff and fixing the regexp if I'm not mistaken. I don't mind if it doesn't become the golden file, the goal is just to hopefully reduce the number of build system, nothing more. Yes, precisely why I mentioned JSON and later gyp, though I don't know if Chromium-specific is the right word here. It even has wx port files in it, which I don't think are built by Chromium. :) I suppose you somehow filter out which ones Chromium should build after the fact? If so, where does that logic reside? Anyway, the fact that this file is actually Python (I had forgotten the format was JSON-like rather than straight JSON) makes things even better, as we only really need to handle export now, and not parse some import file list. i.e. for WebKitTools/Scripts/update-sources-list.py, getWebCoreFilesDict() basically becomes a very small script that execfile's the gypi file, then we run whatever filtering mechanism on it (waf has a list of ports we could use to do the filtering that I could probably move into WebKitTools/Scripts, if we don't have a pre-made Chromium solution here), and then passes the final source list along to generateWebCoreSourcesGTKandQT to generate the sources / includes for those platforms, and actually this solution should work for Android.mk and possibly jam too, as their syntax looks largely similar. Then we'd add some XML parsing code to grab the node for common file groups and update them for the MSVC projects, and then I think that mostly leaves XCode, which I think would be pretty similar in nature. As long as people are willing to test out this solution with their build systems and help with any debugging, I would be willing to help out in hacking it together, though I can't promise anything in the way of time since this is not an immediate concern for me personally. Thanks, Kevin___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
