[webkit-dev] Porting WebKit To a new graphic backend.
hi all, I want to porting webkit to a new graphics library, because I need to rendeting webpage to any platform. The graphic library named Picasso(http://picasso-graphic.googlecode.com/files/picasso12_source.tar.gz). Only a Mobile browser use this port at present(http://www.zncsoft.com/down.html). Picasso is a device independent rendering library. The project home page is http://code.google.com/p/picasso-graphic/ I send a patch to bugs.webkit.org (https://bugs.webkit.org/show_bug.cgi?id=102063) jpzhang ** ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Problems with the new NATIVE_TYPE_ERR
Four months back we added NATIVE_TYPE_ERR for IndexedDB, as a way for the DOM code to raise JavaScript type error exceptions rather than DOM exceptions http://trac.webkit.org/changeset/123112. Yesterday we started using NATIVE_TYPE_ERR elsewhere in the DOM http://trac.webkit.org/changeset/134345. Looking this over, I see some problems. I added comments to https://bugs.webkit.org/show_bug.cgi?id=91679 and https://bugs.webkit.org/show_bug.cgi?id=101604 describing the problems. The new error code is not handled at all in bindings other than the JavaScript bindings. I also think the constant for it is not well named. Using NATIVE_TYPE_ERR in its current state outside IndexedDB causes an immediate showstopper bug for Apple’s Mac version of WebKit and perhaps for others as well. We may want to roll back this recent change until we deal with that. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] commit-queue bot missing a dependency? (ImportError: No module named logilab.astng.utils)
Argh, yeah. Unfortunately, I'm not sure what triggers this problem. It's easy enough to fix as soon as I can find someone w/ access to the CQ. -- Dirk On Tue, Nov 13, 2012 at 7:50 AM, Adam Barth aba...@webkit.org wrote: Sounds related to a recent changed made by dpranke. Adam On Tue, Nov 13, 2012 at 7:33 AM, Jussi Kukkonen jussi.kukko...@intel.com wrote: commit-queue bot seems to be missing a pylint dependency? This is what I got for my rebaseline in https://bugs.webkit.org/show_bug.cgi?id=102059: --- Failed to run ['/mnt/git/webkit-commit-queue/Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '-... exit_code: 2 Last 500 characters of output: yle/checkers/python.py, line 31, in module from webkitpy.thirdparty.autoinstalled.pylint import lint File /mnt/git/webkit-commit-queue/Tools/Scripts/webkitpy/thirdparty/autoinstalled/pylint/lint.py, line 31, in module from pylint.checkers import utils File /mnt/git/webkit-commit-queue/Tools/Scripts/webkitpy/thirdparty/autoinstalled/pylint/checkers/__init__.py, line 44, in module from logilab.astng.utils import ASTWalker ImportError: No module named logilab.astng.utils Full output: http://queues.webkit.org/results/14823414 --- - jussi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Problems with the new NATIVE_TYPE_ERR
On Tue, Nov 13, 2012 at 9:38 AM, Darin Adler da...@apple.com wrote: Four months back we added NATIVE_TYPE_ERR for IndexedDB, as a way for the DOM code to raise JavaScript type error exceptions rather than DOM exceptions http://trac.webkit.org/changeset/123112. Yesterday we started using NATIVE_TYPE_ERR elsewhere in the DOM http://trac.webkit.org/changeset/134345. Looking this over, I see some problems. I added comments to https://bugs.webkit.org/show_bug.cgi?id=91679 and https://bugs.webkit.org/show_bug.cgi?id=101604 describing the problems. The new error code is not handled at all in bindings other than the JavaScript bindings. I also think the constant for it is not well named. Using NATIVE_TYPE_ERR in its current state outside IndexedDB causes an immediate showstopper bug for Apple’s Mac version of WebKit and perhaps for others as well. We may want to roll back this recent change until we deal with that. Rolling http://trac.webkit.org/changeset/134345 out in webkit.org/b/102106 Renaming NATIVE_TYPE_ERR when we have settled on a name (discussion in webkit.org/b/91679 The switch from DOMException of type TYPE_MISMATCH_ERR to TypeError does not appear to be controversial, but as arv@ mentioned in one of the bugs: WebIDL only defines bindings for ECMAScript. We really need someone from Apple to take care of the ObjC bindings, someone from QT for CPP bindings and someone for GTK to take care of the GTK bindings. And by take care of we mean define what a WebIDL TypeError even means in binding XYZ. So - help appreciated. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] commit-queue bot missing a dependency? (ImportError: No module named logilab.astng.utils)
I'm seeing the same on the Android bot. What is the right way to fix this? Cheers, Peter On 13 Nov 2012 18:31, Dirk Pranke dpra...@chromium.org wrote: Argh, yeah. Unfortunately, I'm not sure what triggers this problem. It's easy enough to fix as soon as I can find someone w/ access to the CQ. -- Dirk On Tue, Nov 13, 2012 at 7:50 AM, Adam Barth aba...@webkit.org wrote: Sounds related to a recent changed made by dpranke. Adam On Tue, Nov 13, 2012 at 7:33 AM, Jussi Kukkonen jussi.kukko...@intel.com wrote: commit-queue bot seems to be missing a pylint dependency? This is what I got for my rebaseline in https://bugs.webkit.org/show_bug.cgi?id=102059: --- Failed to run ['/mnt/git/webkit-commit-queue/Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '-... exit_code: 2 Last 500 characters of output: yle/checkers/python.py, line 31, in module from webkitpy.thirdparty.autoinstalled.pylint import lint File /mnt/git/webkit-commit-queue/Tools/Scripts/webkitpy/thirdparty/autoinstalled/pylint/lint.py, line 31, in module from pylint.checkers import utils File /mnt/git/webkit-commit-queue/Tools/Scripts/webkitpy/thirdparty/autoinstalled/pylint/checkers/__init__.py, line 44, in module from logilab.astng.utils import ASTWalker ImportError: No module named logilab.astng.utils Full output: http://queues.webkit.org/results/14823414 --- - jussi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] generic test expectations?
Just checking, but I don't see a way to add test expectations that apply generically (to all ports). It would be nice to have something like LayoutTests/platform/generic/TestExpectations to which one could add new tests that are known to fail everywhere (e.g., because the code that implements a feature that is tested by those tests is not yet committed), but which will (at some point in the near future) not fail (when the code that is to be tested is committed). At present, it seems that if one wishes to do this, then it is necessary to add entries to the each base port expectations (i.e., chromium, mac, win, etc), which is rather annoying. If there is no objection to adding such a generic platform expectations file, then I will undertake to do so. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] generic test expectations?
Just put the expected files in the same directory as the test. Simon On Nov 13, 2012, at 10:49 AM, Glenn Adams gl...@skynav.com wrote: Just checking, but I don't see a way to add test expectations that apply generically (to all ports). It would be nice to have something like LayoutTests/platform/generic/TestExpectations to which one could add new tests that are known to fail everywhere (e.g., because the code that implements a feature that is tested by those tests is not yet committed), but which will (at some point in the near future) not fail (when the code that is to be tested is committed). At present, it seems that if one wishes to do this, then it is necessary to add entries to the each base port expectations (i.e., chromium, mac, win, etc), which is rather annoying. If there is no objection to adding such a generic platform expectations file, then I will undertake to do so. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] generic test expectations?
That would seem to work only if the test(s) fail the same way on all ports. In the case that I'm working from, I'm using reftests, where I know the correct expectations, but the actual behavior will (does) differ on different ports (when the corresponding feature is committed). I would like to be able to (independently) commit new reftests *and* their known good expectation counterparts (that should apply on all ports), and then subsequently commit an independent patch that implements the expected behavior (on some but not all ports), and the comment further follow-on patches that fix the failing ports (possibly by writing new expectations for those specific ports). On Tue, Nov 13, 2012 at 11:52 AM, Ryosuke Niwa rn...@webkit.org wrote: It is customary to add a failing test expectation (i.e. *-expected.txt file that contains the said failure) in such cases. On Tue, Nov 13, 2012 at 10:49 AM, Glenn Adams gl...@skynav.com wrote: Just checking, but I don't see a way to add test expectations that apply generically (to all ports). It would be nice to have something like LayoutTests/platform/generic/TestExpectations to which one could add new tests that are known to fail everywhere (e.g., because the code that implements a feature that is tested by those tests is not yet committed), but which will (at some point in the near future) not fail (when the code that is to be tested is committed). At present, it seems that if one wishes to do this, then it is necessary to add entries to the each base port expectations (i.e., chromium, mac, win, etc), which is rather annoying. If there is no objection to adding such a generic platform expectations file, then I will undertake to do so. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] generic test expectations?
On Tue, Nov 13, 2012 at 12:02 PM, Glenn Adams gl...@skynav.com wrote: implements the expected behavior (on some but not all ports), and the comment further follow-on s/the comment further/then commit further/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] generic test expectations?
We don't currently support port-specific reftests (or at least, not very well), and we certainly should be trying to minimize where they occur. Perhaps we should discuss why you need them (in a separate thread with a separate subject line)? It sounds like this largely has to do with what features are enabled and/or supported? Perhaps said tests should just be skipped in the meantime? At any rate, we encourage people these days to check in expected failures rather than suppressing them using the TestExpectations files. I am hoping this week to finally get back to working on the -failing feature so you can at least distinguish expectations that are known to be failing/incorrect more easily. -- Dirk On Tue, Nov 13, 2012 at 11:02 AM, Glenn Adams gl...@skynav.com wrote: That would seem to work only if the test(s) fail the same way on all ports. In the case that I'm working from, I'm using reftests, where I know the correct expectations, but the actual behavior will (does) differ on different ports (when the corresponding feature is committed). I would like to be able to (independently) commit new reftests *and* their known good expectation counterparts (that should apply on all ports), and then subsequently commit an independent patch that implements the expected behavior (on some but not all ports), and the comment further follow-on patches that fix the failing ports (possibly by writing new expectations for those specific ports). On Tue, Nov 13, 2012 at 11:52 AM, Ryosuke Niwa rn...@webkit.org wrote: It is customary to add a failing test expectation (i.e. *-expected.txt file that contains the said failure) in such cases. On Tue, Nov 13, 2012 at 10:49 AM, Glenn Adams gl...@skynav.com wrote: Just checking, but I don't see a way to add test expectations that apply generically (to all ports). It would be nice to have something like LayoutTests/platform/generic/TestExpectations to which one could add new tests that are known to fail everywhere (e.g., because the code that implements a feature that is tested by those tests is not yet committed), but which will (at some point in the near future) not fail (when the code that is to be tested is committed). At present, it seems that if one wishes to do this, then it is necessary to add entries to the each base port expectations (i.e., chromium, mac, win, etc), which is rather annoying. If there is no objection to adding such a generic platform expectations file, then I will undertake to do so. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Problems with the new NATIVE_TYPE_ERR
On Nov 13, 2012, at 10:44 AM, Joshua Bell jsb...@chromium.org wrote: The switch from DOMException of type TYPE_MISMATCH_ERR to TypeError does not appear to be controversial, but as arv@ mentioned in one of the bugs: WebIDL only defines bindings for ECMAScript. We really need someone from Apple to take care of the ObjC bindings, someone from QT for CPP bindings and someone for GTK to take care of the GTK bindings. And by take care of we mean define what a WebIDL TypeError even means in binding XYZ. So - help appreciated. It seems to me that translating TypeError into TYPE_MISMATCH_ERR in each of those bindings would be an acceptable stopgap while we investigate “what TypeError event means” for that binding and would get rid of the mechanical problem of having to do this all at once. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] generic test expectations?
On Tue, Nov 13, 2012 at 11:02 AM, Glenn Adams gl...@skynav.com wrote: That would seem to work only if the test(s) fail the same way on all ports. In the case that I'm working from, I'm using reftests, where I know the correct expectations, but the actual behavior will (does) differ on different ports (when the corresponding feature is committed). That seems to indicate that ref test is not a good testing method for this feature. I would like to be able to (independently) commit new reftests *and* their known good expectation counterparts (that should apply on all ports), and then subsequently commit an independent patch that implements the expected behavior (on some but not all ports), and the comment further follow-on patches that fix the failing ports (possibly by writing new expectations for those specific ports). What kind of tests are you trying to add? Assuming this is related to your line break work, it might be possible to convert your tests to dumpAsText tests using getComputedStyle and check in failing *-expected.txt files. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] generic test expectations?
On Tue, Nov 13, 2012 at 12:09 PM, Dirk Pranke dpra...@chromium.org wrote: We don't currently support port-specific reftests (or at least, not very well), and we certainly should be trying to minimize where they occur. Hmm, I actually used port specific reftest expectation files in a recent patch [1] (since rolled out), and it appeared to work (as a way to effectively rebaseline those expectations). So something seems to be working. [1] http://trac.webkit.org/changeset/133529 At any rate, we encourage people these days to check in expected failures rather than suppressing them using the TestExpectations files. The problem is essentially a chicken and egg problem. I don't know what the per-port failures will be ahead of time, but I do know the set of correct expectations. Since I am (independently) unable to build/test all ports run by build bots, I would like to commit the set of tests plus known good expectations as a preliminary step (with a generic skip all tests for all ports), and then subsequently commit the feature itself, and then subsequently override the generic skip on a port specific basis, effectively re-enabling the tests on a port by port basis as I refine the feature patch (as needed) to handle port specific behavioral differences. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] generic test expectations?
On Tue, Nov 13, 2012 at 11:29 AM, Glenn Adams gl...@skynav.com wrote: On Tue, Nov 13, 2012 at 12:09 PM, Dirk Pranke dpra...@chromium.org wrote: We don't currently support port-specific reftests (or at least, not very well), and we certainly should be trying to minimize where they occur. Hmm, I actually used port specific reftest expectation files in a recent patch [1] (since rolled out), and it appeared to work (as a way to effectively rebaseline those expectations). So something seems to be working. [1] http://trac.webkit.org/changeset/133529 I expect it'll sort of work, but it won't be robust; you may hit weird behavior and/or bugs. We really haven't beaten on this aspect of things, and I don't know yet how much we want to. At any rate, we encourage people these days to check in expected failures rather than suppressing them using the TestExpectations files. The problem is essentially a chicken and egg problem. I don't know what the per-port failures will be ahead of time, but I do know the set of correct expectations. Since I am (independently) unable to build/test all ports run by build bots, I would like to commit the set of tests plus known good expectations as a preliminary step (with a generic skip all tests for all ports), and then subsequently commit the feature itself, and then subsequently override the generic skip on a port specific basis, effectively re-enabling the tests on a port by port basis as I refine the feature patch (as needed) to handle port specific behavioral differences. I think this is a reasonable approach. I would be interested to hear if others had alternatives they preferred. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] generic test expectations?
If we do add base test expectations shared by all platforms, please don’t put the file into LayoutTests/platform/generic; just put it at the top level of LayoutTests. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] do you want WK1 and WK2 keywords in the TestExpectations files?
Hi all, I occasionally get asked if the TestExpectations syntax supports a way to distinguish different results for WebKit1 and WebKit2 via keywords. We currently don't do this, and different ports have worked around this in slightly different ways by using dedicated wk2-specific TestExpectations files and sometimes wk1-specific TestExpectations files. However, this is a little awkward and gets worse if you also need to support different expectations for multiple different configs (e.g., mac-lion vs mac-snowleopard vs mac-mountainlion). So, it seems like WK1 and WK2 keywords might be useful. However, I don't really want to add more divergence between ports, so it would be nice to have everyone agree to use it if we were to add it. What do you all think? Would you like this feature, and would you all use it ? (Since I don't regularly switch between WK1 and WK2 I don't have a strong feeling here beyond what I've written above). -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] do you want WK1 and WK2 keywords in the TestExpectations files?
I don't have strong opinions on this, but one advantage of using the keywords and getting rid of the dedicated TestExpectations files would be to make the fallback graph actually be a tree instead of a DAG. This would simplify the rebaselining tooling considerably and allow us to make a bunch of cases work better that don't work great right now. On Tue, Nov 13, 2012 at 11:41 AM, Dirk Pranke dpra...@chromium.org wrote: Hi all, I occasionally get asked if the TestExpectations syntax supports a way to distinguish different results for WebKit1 and WebKit2 via keywords. We currently don't do this, and different ports have worked around this in slightly different ways by using dedicated wk2-specific TestExpectations files and sometimes wk1-specific TestExpectations files. However, this is a little awkward and gets worse if you also need to support different expectations for multiple different configs (e.g., mac-lion vs mac-snowleopard vs mac-mountainlion). So, it seems like WK1 and WK2 keywords might be useful. However, I don't really want to add more divergence between ports, so it would be nice to have everyone agree to use it if we were to add it. What do you all think? Would you like this feature, and would you all use it ? (Since I don't regularly switch between WK1 and WK2 I don't have a strong feeling here beyond what I've written above). -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] do you want WK1 and WK2 keywords in the TestExpectations files?
Dirk Pranke dpra...@chromium.org writes: So, it seems like WK1 and WK2 keywords might be useful. However, I don't really want to add more divergence between ports, so it would be nice to have everyone agree to use it if we were to add it. What do you all think? Would you like this feature, and would you all use it ? At least on the EFL side I think things are good the way they are: we have platform/efl for common stuff and platform/efl-wk1 and platform/efl-wk2 for WK1- or WK2-specific stuff (not only TestExpectations files but also test results). If we got rid of those and put everything together in platform/efl, I think we'd end up with a very big TestExpectations file and don't know what we'd do with the occasional different results for WK1 and WK2. However, this is a little awkward and gets worse if you also need to support different expectations for multiple different configs (e.g., mac-lion vs mac-snowleopard vs mac-mountainlion). It wouldn't really solve this problem, right? -- Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] generic test expectations?
On Tue, Nov 13, 2012 at 11:35 AM, Dirk Pranke dpra...@chromium.org wrote: On Tue, Nov 13, 2012 at 11:29 AM, Glenn Adams gl...@skynav.com wrote: On Tue, Nov 13, 2012 at 12:09 PM, Dirk Pranke dpra...@chromium.org wrote: We don't currently support port-specific reftests (or at least, not very well), and we certainly should be trying to minimize where they occur. Hmm, I actually used port specific reftest expectation files in a recent patch [1] (since rolled out), and it appeared to work (as a way to effectively rebaseline those expectations). So something seems to be working. [1] http://trac.webkit.org/changeset/133529 I expect it'll sort of work, but it won't be robust; you may hit weird behavior and/or bugs. We really haven't beaten on this aspect of things, and I don't know yet how much we want to. I don't think we should support port specific ref test results. That kind of misses the point of using a ref test in the first place. I mean, you may as well check in port specific pixel results which are easier to review for correctness. It may be the case that a ref test is not appropriate for what you're trying to test. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] generic test expectations?
On Tue, Nov 13, 2012 at 12:04 PM, Darin Adler da...@apple.com wrote: On Nov 13, 2012, at 12:02 PM, Tony Chang t...@chromium.org wrote: I don't think we should support port specific ref test results. That kind of misses the point of using a ref test in the first place. I mean, you may as well check in port specific pixel results which are easier to review for correctness. I don’t agree that pixel results are easier to review for correctness. Here is a ref test result from ietestcenter: http://trac.webkit.org/browser/trunk/LayoutTests/ietestcenter/css3/flexbox/flexbox-flex-002-expected.htm Looking at that HTML file, it's not immediately obvious that the result is correct. If I had a png file, it would easy to see if there's red showing or not. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] generic test expectations?
On Tue, Nov 13, 2012 at 12:02 PM, Tony Chang t...@chromium.org wrote: On Tue, Nov 13, 2012 at 11:35 AM, Dirk Pranke dpra...@chromium.org wrote: On Tue, Nov 13, 2012 at 11:29 AM, Glenn Adams gl...@skynav.com wrote: On Tue, Nov 13, 2012 at 12:09 PM, Dirk Pranke dpra...@chromium.org wrote: We don't currently support port-specific reftests (or at least, not very well), and we certainly should be trying to minimize where they occur. Hmm, I actually used port specific reftest expectation files in a recent patch [1] (since rolled out), and it appeared to work (as a way to effectively rebaseline those expectations). So something seems to be working. [1] http://trac.webkit.org/changeset/133529 I expect it'll sort of work, but it won't be robust; you may hit weird behavior and/or bugs. We really haven't beaten on this aspect of things, and I don't know yet how much we want to. I don't think we should support port specific ref test results. That kind of misses the point of using a ref test in the first place. I mean, you may as well check in port specific pixel results which are easier to review for correctness. It may be the case that a ref test is not appropriate for what you're trying to test. I think that there are probably cases where we will have differences in results because of (legal and entirely correct or permissible) differences in the implementations and in this case a reftest can still be an improvement over maintaining N platform-specific pixel versions. The obvious example is when we haven't implemented features yet (or have bugs). The W3C's spec for handling reftests also gives you a way to say a test passes if any of these N references may match, which is fairly consistent with the idea that platform specific references are okay in some cases. As to whether pixel-tests are easier to review for correctness than reftests or not, I think it depends on the test. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Porting WebKit To a new graphic backend.
On Tue, Nov 13, 2012 at 9:03 AM, ZhangJiPeng oneco...@gmail.com wrote: I want to porting webkit to a new graphics library, because I need to rendeting webpage to any platform. The graphic library named Picasso( http://picasso-graphic.googlecode.com/files/picasso12_source.tar.gz). Only a Mobile browser use this port at present( http://www.zncsoft.com/down.html). Picasso is a device independent rendering library. The project home page is http://code.google.com/p/picasso-graphic/ I send a patch to bugs.webkit.org ( https://bugs.webkit.org/show_bug.cgi?id=102063) Can you give us some more context? Which port uses that? Why not just use Cairo or Skia? etc. A quick check on http://code.google.com/p/picasso-graphic/ shows it uses this other project for the rasterization: http://www.antigrain.com AGG seems dead since 2006. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] do you want WK1 and WK2 keywords in the TestExpectations files?
On Nov 13, 2012, at 12:29 PM, Dirk Pranke dpra...@chromium.org wrote: We pretty much have this today (with platform/wk2 and platform/mac-wk2). You're saying you'd prefer to add platform/wk1, platform/mac-wk1, platform/mac-lion-wk1, and platform/mac-lion-wk2 if/where necessary (and no keywords), right? I would prefer it to adding keywords. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] do you want WK1 and WK2 keywords in the TestExpectations files?
On Tue, Nov 13, 2012 at 12:29 PM, Dirk Pranke dpra...@chromium.org wrote: On Tue, Nov 13, 2012 at 12:13 PM, Darin Adler da...@apple.com wrote: I’d prefer an directory-based overlay/inheritance approach to sharing WebKit1- vs. WebKit2-specific expectations over in-file keywords. I’d like to share more than just a central expectations file, so we could share expected results or even WebKit1 or WebKit2-specific tests. We pretty much have this today (with platform/wk2 and platform/mac-wk2). You're saying you'd prefer to add platform/wk1, platform/mac-wk1, platform/mac-lion-wk1, and platform/mac-lion-wk2 if/where necessary (and no keywords), right? One specific example to motivate this ... imagine a test that we want to skip everywhere except current (and future) mac wk2. This would require a Skip in platform/mac/TestExpectations, a Pass in platform/mac-wk2/TestExpectations, and then a Skip in (a newly created, since we don't currently have this) platform/mac-lion-wk2/TestExpectations. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Porting WebKit To a new graphic backend.
You might want to look at the Chromium content framework. It's based on webkit and is already ported to several platforms. On Tue, Nov 13, 2012 at 1:32 PM, Benjamin Poulain benja...@webkit.orgwrote: On Tue, Nov 13, 2012 at 9:03 AM, ZhangJiPeng oneco...@gmail.com wrote: I want to porting webkit to a new graphics library, because I need to rendeting webpage to any platform. The graphic library named Picasso( http://picasso-graphic.googlecode.com/files/picasso12_source.tar.gz). Only a Mobile browser use this port at present( http://www.zncsoft.com/down.html). Picasso is a device independent rendering library. The project home page is http://code.google.com/p/picasso-graphic/ I send a patch to bugs.webkit.org ( https://bugs.webkit.org/show_bug.cgi?id=102063) Can you give us some more context? Which port uses that? Why not just use Cairo or Skia? etc. A quick check on http://code.google.com/p/picasso-graphic/ shows it uses this other project for the rasterization: http://www.antigrain.com AGG seems dead since 2006. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] sharing more test references
Hi all, Currently, we have ~8000 pixel tests in the tree, and ~800 reference tests. I would like to make that first number a lot smaller. It turns out that we have a reasonably large number of tests that produce the exact same pixel results. On chromium-mac on 10.8, for example, there are 2048 tests that share a result with some other test. 50 of them, for example, draw a green square in the upper left corner of the page (e.g., for svg/custom/root-element.html). The way ref tests are currently implemented, there is no direct way to say use test X as a reference for test Y (although this is in the W3C specs for ref tests, which suggests using link tags in the test html). Previous conversations on this topic have concluded with us thinking that we don't want to give up the convention of having an -expected file next to each test, and I still think this is a good idea. However, we can probably have our cake and eat it too in many cases by simply doing something like creating an -expected.html file that contains solely iframe src=path-to-X. So, I would like to : 1) document that as an accepted pattern somewhere 2) start building up a directory of shared references, e.g., LayoutTests/references/green-square.html 3) start converting existing pixel tests to use these. Anyone think this won't, work, otherwise object, or have better ideas? -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding blending mode to WebKit canvas
Maciej, did this sound reasonable to you? Would you object if Canvas combines blending and compositing but not CSS? Rik On Mon, Nov 12, 2012 at 3:46 PM, Rik Cabanier caban...@gmail.com wrote: On Mon, Nov 12, 2012 at 12:14 PM, Maciej Stachowiak m...@apple.com wrote: On Nov 11, 2012, at 9:06 PM, Rik Cabanier caban...@gmail.com wrote: On Sun, Nov 11, 2012 at 8:43 PM, Maciej Stachowiak m...@apple.com wrote: On Nov 11, 2012, at 6:59 PM, Rik Cabanier caban...@gmail.com wrote: Wouldn't it be better to add a new property to canvas for blending? At the beginning, implementations are just require to use different blend modes in combination with 'source-over'. That could work too. There was a mailing list conversation about this a couple of months ago, and people were evenly split on the subject. The vast majority of cases will use 'source-over' in combination with blending so maybe it's best to keep it simple... It doesn't make sense to me for blend mode and composite operator to be separate in CSS, but combined in Canvas. Either there are valid use cases for specifying them separately or there are not. I cannot imagine how this could differ between Canvas and CSS. There are cases where it makes sense to have them as separate properties. To be honest, the main reason that the Canvas proposal combines them, is because it is not possible to implement this efficiently using Core Graphics. If we break it up in 2 operations, we have to document the correct behavior (= blending does not force source-over for blending) because the spec can't be changed later. This means that Safari and Firefox for Mac can only implement part of the spec... I prefer to have a consistent implementation that can be extended later as opposed to a 'correct' API that is inconsistently implemented. Doesn't this same argument apply to CSS blend modes? (And therefore the 'blend-mode' and 'alpha-compositing' properties should be combined into a single property)? Yes, except I'm not proposing that we implement the 'alpha-compositing' property yet. I hope that MacOS (or Safari) can evolve in the future so it can be implemented more easily. Compositing in CSS is actually a much harder problem than in Canvas because it requires the UA to keep track of the 'shape'. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] sharing more test references
On Nov 13, 2012, at 4:01 PM, Dirk Pranke dpra...@chromium.org wrote: It turns out that we have a reasonably large number of tests that produce the exact same pixel results. On chromium-mac on 10.8, for example, there are 2048 tests that share a result with some other test. 50 of them, for example, draw a green square in the upper left corner of the page (e.g., for svg/custom/root-element.html). It seems to me that when we find a pattern like this, we should create a hand-coded reference test result. The fact that so many tests produce the same pixels means that each reference can be used to move a lot of tests from the pixel test to the reference test category. I don’t think we need to do that iframe thing you said, as long as there are large sets of tests with the same result, since if the payoff for each reference is big enough, it should be affordable to hand-write the reference file. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] sharing more test references
On Tue, Nov 13, 2012 at 4:33 PM, Darin Adler da...@apple.com wrote: On Nov 13, 2012, at 4:01 PM, Dirk Pranke dpra...@chromium.org wrote: It turns out that we have a reasonably large number of tests that produce the exact same pixel results. On chromium-mac on 10.8, for example, there are 2048 tests that share a result with some other test. 50 of them, for example, draw a green square in the upper left corner of the page (e.g., for svg/custom/root-element.html). It seems to me that when we find a pattern like this, we should create a hand-coded reference test result. The fact that so many tests produce the same pixels means that each reference can be used to move a lot of tests from the pixel test to the reference test category. I don’t think we need to do that iframe thing you said, as long as there are large sets of tests with the same result, since if the payoff for each reference is big enough, it should be affordable to hand-write the reference file. I don't think I'm understanding you. Wouldn't the fact that there are a large set of tests with the same result be an argument *for* doing the iframe thing? What is the advantage to having 50 copies of a hand-coded green square in upper left corner reference test? -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] sharing more test references
On Nov 13, 2012, at 4:56 PM, Dirk Pranke dpra...@chromium.org wrote: Wouldn't the fact that there are a large set of tests with the same result be an argument *for* doing the iframe thing? The simple hand-coded green square in upper left corner should be simple, perhaps even simpler than the iframe thing. What is the advantage to having 50 copies of a hand-coded green square in upper left corner reference test? Tests standing alone and being independent, easy to move around, revise, and understand individually rather than as part of a suite. I don’t have a strong objection to your iframe technique, but I’d start simpler and do it only if it’s really needed. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] sharing more test references
!DOCTYPE html body style=margin: 0px div style=height: 100px; width: 100px; background-color: green Does seem pretty simple. !DOCTYPE html body style=margin: 0px svgrect width=100px height=100px fill=greensvg is even shorter. :) I support getting rid of pixel tests. I suspect that some very dumb scripts could turn large chunks of these existing pixel-tests into ref-tests. I doubt that those would be the interesting ones though (where platforms have divergent results). On Tue, Nov 13, 2012 at 4:59 PM, Darin Adler da...@apple.com wrote: On Nov 13, 2012, at 4:56 PM, Dirk Pranke dpra...@chromium.org wrote: Wouldn't the fact that there are a large set of tests with the same result be an argument *for* doing the iframe thing? The simple hand-coded green square in upper left corner should be simple, perhaps even simpler than the iframe thing. What is the advantage to having 50 copies of a hand-coded green square in upper left corner reference test? Tests standing alone and being independent, easy to move around, revise, and understand individually rather than as part of a suite. I don’t have a strong objection to your iframe technique, but I’d start simpler and do it only if it’s really needed. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] sharing more test references
On Tue, Nov 13, 2012 at 4:59 PM, Darin Adler da...@apple.com wrote: On Nov 13, 2012, at 4:56 PM, Dirk Pranke dpra...@chromium.org wrote: Wouldn't the fact that there are a large set of tests with the same result be an argument *for* doing the iframe thing? The simple hand-coded green square in upper left corner should be simple, perhaps even simpler than the iframe thing. What is the advantage to having 50 copies of a hand-coded green square in upper left corner reference test? Tests standing alone and being independent, easy to move around, revise, and understand individually rather than as part of a suite. Got it. It seems like referencing a well-known result makes things easier to understand, not harder, once you see it at least once, but I imagine it certainly depends on the complexity of the result. E.g., PASSED is better than iframe src='path-to-test-containing-the-word-passed'. Past about four lines it seems like the iframe would win. I don’t have a strong objection to your iframe technique, but I’d start simpler and do it only if it’s really needed. I will also note that there are a large number of tests where we seem to have duplicate results, e.g., dom/html/level1 and dom/xhtml/level1 where the results are basically the same between the two suites, and having the xhtml results just be iframe'd versions of the html one seems like it would make sense. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] sharing more test references
On Tue, Nov 13, 2012 at 5:06 PM, Eric Seidel e...@webkit.org wrote: !DOCTYPE html body style=margin: 0px div style=height: 100px; width: 100px; background-color: green Does seem pretty simple. !DOCTYPE html body style=margin: 0px svgrect width=100px height=100px fill=greensvg is even shorter. :) I support getting rid of pixel tests. I suspect that some very dumb scripts could turn large chunks of these existing pixel-tests into ref-tests. I doubt that those would be the interesting ones though (where platforms have divergent results). I've been spending a fair amount of time working on this, actually. I think it's harder than you might think. I'm happy to talk further about it. From what I can tell, we get most of divergence between platforms from the fact that we render text differently everywhere and we tend to render controls differently everywhere. Most of the time the differences are unrelated to what's actually being tested, unfortunately :(. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Porting WebKit To a new graphic backend.
于 2012-11-14 4:32, Benjamin Poulain 写道: On Tue, Nov 13, 2012 at 9:03 AM, ZhangJiPeng oneco...@gmail.com mailto:oneco...@gmail.com wrote: I want to porting webkit to a new graphics library, because I need to rendeting webpage to any platform. The graphic library named Picasso(http://picasso-graphic.googlecode.com/files/picasso12_source.tar.gz). Only a Mobile browser use this port at present(http://www.zncsoft.com/down.html). Picasso is a device independent rendering library. The project home page is http://code.google.com/p/picasso-graphic/ I send a patch to bugs.webkit.org http://bugs.webkit.org (https://bugs.webkit.org/show_bug.cgi?id=102063) Can you give us some more context? Which port uses that? Why not just use Cairo or Skia? etc. A quick check on http://code.google.com/p/picasso-graphic/ shows it uses this other project for the rasterization: http://www.antigrain.com AGG seems dead since 2006. Benjamin The idea came from an embedded browser development project. I want to porting WebKit to a new platform, the platform can only provide video address programming interface. So I need to porting DirectFB, Cairo, GTK and so on. However the hardware resources are limited, can't running so much software, I need to find a more lightweight and high quality solutions, so I develop the picasso library. The same code base can run on different graphics system does not depend on the features of graphic system, this is the goal of Picasso. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Porting WebKit To a new graphic backend.
? 2012-11-14 5:36, Jake ??: You might want to look at the Chromium content framework. It's based on webkit and is already ported to several platforms. On Tue, Nov 13, 2012 at 1:32 PM, Benjamin Poulain benja...@webkit.org mailto:benja...@webkit.org wrote: On Tue, Nov 13, 2012 at 9:03 AM, ZhangJiPeng oneco...@gmail.com mailto:oneco...@gmail.com wrote: I want to porting webkit to a new graphics library, because I need to rendeting webpage to any platform. The graphic library named Picasso(http://picasso-graphic.googlecode.com/files/picasso12_source.tar.gz). Only a Mobile browser use this port at present(http://www.zncsoft.com/down.html). Picasso is a device independent rendering library. The project home page is http://code.google.com/p/picasso-graphic/ I send a patch to bugs.webkit.org http://bugs.webkit.org (https://bugs.webkit.org/show_bug.cgi?id=102063) Can you give us some more context? Which port uses that? Why not just use Cairo or Skia? etc. A quick check on http://code.google.com/p/picasso-graphic/ shows it uses this other project for the rasterization: http://www.antigrain.com AGG seems dead since 2006. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev Thank you, I will refer to that. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] RenderArena: Teaching an old dog new tricks
RenderArena was a perf optimization for the rendering tree, which hyatt imported from Mozilla 10 years ago: http://trac.webkit.org/changeset/2635 The prevailing lore has long been that RenderArena is no longer useful, ugly, and should be killed! http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg12681.html The (unfortunate?) reality is that we've failed to do so, despite trying several times. http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg12682.html However, like those bell-bottoms in your father's closet, RenderArena is back in vogue and Chromium's security team very excited about RenderArena's security benefits. Why, you might ask? Slab-allocators (i.e. RenderArena) hand out memory all from a single region, guaranteeing (among other things) that free'd objects can only be ever overwritten by other objects from the same pool. This makes it much harder, for example to find a Use-After-Free of a RenderBlock and then fill that RenderBlock's memory (and vtable pointer) with arbitrary memory (like the contents of a javascript array). http://en.wikipedia.org/wiki/Slab_allocation We're aware of multiple high-profile past WebKit exploits (including the last $60,000-winning Pwnium 2 exploit) which would have been defeated by a Slab-allocated DOM. Various members of Chromium's security team have also been working on improving RenderArena: http://trac.webkit.org/changeset/133119 http://trac.webkit.org/changeset/132970 http://trac.webkit.org/changeset/129583 http://trac.webkit.org/changeset/97009 Since RenderArena is generic, the current plan to move it to WTF (as by Chris Marrin suggested back in http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg12672.html), clean up the code further, and investigate wider deployment (like to the DOM tree) for the security benefit and possible perf win. https://bugs.webkit.org/show_bug.cgi?id=101087 Also on the list is making our smart-pointers (OwnPtr,ReftPtr) smarter, to avoid the current manual use/free mess of current RenderArena clients. Personally, I hope we bring back mullets next. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] RenderArena: Teaching an old dog new tricks
Eric Seidel wrote: However, like those bell-bottoms in your father's closet, RenderArena is back in vogue and Chromium's security team very excited about RenderArena's security benefits. Disco, like the drive-in, will never die. http://robert.ocallahan.org/2010/10/mitigating-dangling-pointer-bugs-using_15.html discusses the frame-poisoning work in Gecko. It saved us from quite a number of potential 0days in the last two years, as far as I can tell. /be ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] RenderArena: Teaching an old dog new tricks
On Tue, Nov 13, 2012 at 10:23 PM, Eric Seidel e...@webkit.org wrote: RenderArena was a perf optimization for the rendering tree, which hyatt imported from Mozilla 10 years ago: http://trac.webkit.org/changeset/2635 The prevailing lore has long been that RenderArena is no longer useful, ugly, and should be killed! http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg12681.html The (unfortunate?) reality is that we've failed to do so, despite trying several times. http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg12682.html I don't think we have failed. The messages posted on the thread don't indicate anyone has tried to delete the render arena recently. I support any attempts to remove it. Since RenderArena is generic, the current plan to move it to WTF (as by Chris Marrin suggested back in http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg12672.html), clean up the code further, and investigate wider deployment (like to the DOM tree) for the security benefit and possible perf win. https://bugs.webkit.org/show_bug.cgi?id=101087 How does this work when a node is adopted from one document to another? DOM arena (or whatever we call it) will not be tied to a document? - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding blending mode to WebKit canvas
On Nov 13, 2012, at 4:43 PM, Rik Cabanier caban...@gmail.com wrote: Maciej, did this sound reasonable to you? Still doesn't make sense to me. Even if we don't implement CSS 'alpha-compositing' and 'blend-mode' today, I assume we will want to implement them eventually. At that point we will want them consistent with Canvas. If the only reason to combine compositing operator and blend modes is short-term ease of implementation on Mac, then that doesn't seem like a great reason to make the Web platform permanently inconsistent. Would you object if Canvas combines blending and compositing but not CSS? Yes. I think they should be consistent and the relevant standards group (FX Task Force?) should decide. It's not even very important to me which is chosen. It just seems arbitrary that they would make different choices on this, especially when it is all defined in the same spec. Regards, Maciej Rik On Mon, Nov 12, 2012 at 3:46 PM, Rik Cabanier caban...@gmail.com wrote: On Mon, Nov 12, 2012 at 12:14 PM, Maciej Stachowiak m...@apple.com wrote: On Nov 11, 2012, at 9:06 PM, Rik Cabanier caban...@gmail.com wrote: On Sun, Nov 11, 2012 at 8:43 PM, Maciej Stachowiak m...@apple.com wrote: On Nov 11, 2012, at 6:59 PM, Rik Cabanier caban...@gmail.com wrote: Wouldn't it be better to add a new property to canvas for blending? At the beginning, implementations are just require to use different blend modes in combination with 'source-over'. That could work too. There was a mailing list conversation about this a couple of months ago, and people were evenly split on the subject. The vast majority of cases will use 'source-over' in combination with blending so maybe it's best to keep it simple... It doesn't make sense to me for blend mode and composite operator to be separate in CSS, but combined in Canvas. Either there are valid use cases for specifying them separately or there are not. I cannot imagine how this could differ between Canvas and CSS. There are cases where it makes sense to have them as separate properties. To be honest, the main reason that the Canvas proposal combines them, is because it is not possible to implement this efficiently using Core Graphics. If we break it up in 2 operations, we have to document the correct behavior (= blending does not force source-over for blending) because the spec can't be changed later. This means that Safari and Firefox for Mac can only implement part of the spec... I prefer to have a consistent implementation that can be extended later as opposed to a 'correct' API that is inconsistently implemented. Doesn't this same argument apply to CSS blend modes? (And therefore the 'blend-mode' and 'alpha-compositing' properties should be combined into a single property)? Yes, except I'm not proposing that we implement the 'alpha-compositing' property yet. I hope that MacOS (or Safari) can evolve in the future so it can be implemented more easily. Compositing in CSS is actually a much harder problem than in Canvas because it requires the UA to keep track of the 'shape'. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] RenderArena: Teaching an old dog new tricks
On Nov 13, 2012, at 10:23 PM, Eric Seidel e...@webkit.org wrote: We're aware of multiple high-profile past WebKit exploits (including the last $60,000-winning Pwnium 2 exploit) which would have been defeated by a Slab-allocated DOM. Some of RenderArena's basic assumptions are that no renderers can outlive the root of their render tree, and that renderers can never be moved from one render tree to another. These are correct for render objects but not DOM nodes. I don't know if this is a fatal obstacle but it is certainly not obvious how to address it. You could force a DOM Arena to stay alive so long as any of its associated DOM nodes was alive, but this has the potential to lead to pathological levels of memory fragmentation. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
