Re: [webkit-dev] Tree red, unsure how to proceed
Most platforms are passing now, except for Windows. I tried adding platform/win results, but that didn't work. I will look again tomorrow morning and try to figure this out. If someone has an idea of how to fix the Windows results before then, feel free to do so. I'm not sure how these tests ever passed on Windows. - Adele On Dec 13, 2009, at 10:28 PM, Adele Peterson wrote: Sorry about that - I'll take a look in the next hour. Sent from my iPhone On Dec 13, 2009, at 9:06 PM, Adam Barth aba...@webkit.org wrote: It appears that http://trac.webkit.org/changeset/52071 broke LayoutTests/fast/css/opacity-float.html on most (all?) platforms. As of this writing, this has been in the tree for six hours with no resolution and no one seems to be on IRC. Normally I would revert the change, but this change appears to be a revert of an earlier change. I'm not really sure how to proceed, but hopefully someone on this list will know what to do (and what advice to give for future situations like this one). Adam ___ 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] what is needed to new backend
Hi all, I would like to know what should a GUI toolkit provide as features to be a suitable backend for WebKit? regards haithem -- Say: He is God, the One and Only; God, the Eternal, Absolute; He begetteth not, nor is He begotten; And there is none like unto Him. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedScript: next steps and result of offline discussion.
How does reparenting across in-place frame navigations work in this scheme? Is a de-parented iframe guaranteed to linger long enough for the new page to get it by name and re-parent it if desired? On Thu, Dec 3, 2009 at 7:01 PM, Dmitry Titov dim...@chromium.org wrote: Hi WebKit, The recent discussion indicated there is a feeling that SharedScript functionality can be achieved by other means that do not require adding new big APIs: changing iframe a bit (so it's internals survive reparenting into another document) and adding single getWindowByName() API. Ian Hickson proposed this idea noting that nothing in the spec prevents iframe from staying alive over the reparenting. Some folks from Google met with folks from Apple to discuss and it appears there is a consensus that we shall remove initial code for SharedScript and instead implement changes for iframe and getWindowByFrame(). This will not cause new API and hopefully won't cause compatibility issues since the only scenario that will behave differently is reparenting of the iframe between documents that is hopefully a rare thing. Perhaps more discussion will be needed to nail details on those. Separately (or related?), we discussed SharedWorkers and the way XHR works in them. It seems a good idea to investigate a shadow document' solution (as Chrome does for worker processes) when a dummy document is created and used to load resources on behalf of the worker. Also we'll try to fix couple of bugs that prevent Workers to be reliable enough. Thanks a lot to all who chimed in and helped to arrive to a good solution to the same issues that SharedScript was trying to solve! :-) Dmitry Titov ___ 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-changes] [52125] trunk/LayoutTests
For predictable failures like these, Darin Adler says the best thing to do is land the expected failure as an expected result, and use a bug to track the fact that it’s wrong. [1] But maybe in the case of tests that time out, it's best to skip them in order to keep the regression tests from slowing down? -Adam 1. http://thread.gmane.org/gmane.os.opendarwin.webkit.devel/10002/focus=10017 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Should we put the webkit.org mailing lists on Gmane?
On Jun 13, 2009, at 9:00 AM, Adam Roben wrote: I think it would be good to put our mailing lists on Gmane (including importing the archives of the lists). The lists are now all on Gmane. Archives for the newer lists have not been imported, but Gmane already has data going back to July 2009. The newsgroups all fall under the gmane.os.opendarwin.webkit prefix, to match the already-existing gmane.os.opendarwin.webkit.devel group. The group names (and their equivalent lists.webkit.org lists) are: gmane.os.opendarwin.webkit. devel (webkit-dev) gtk (webkit-gtk) jobs (webkit-jobs) qt (webkit-qt) user (webkit-help) (user was chosen by the Gmane administrators, presumably to match other projects' groups.) -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Should we put the webkit.org mailing lists on Gmane?
On Mon, December 14, 2009 at 6:47:50 PM, Adam Roben wrote: On Jun 13, 2009, at 9:00 AM, Adam Roben wrote: I think it would be good to put our mailing lists on Gmane (including importing the archives of the lists). The lists are now all on Gmane. Archives for the newer lists have not been imported, but Gmane already has data going back to July 2009. The newsgroups all fall under the gmane.os.opendarwin.webkit prefix, to match the already-existing gmane.os.opendarwin.webkit.devel group. The group names (and their equivalent lists.webkit.org lists) are: gmane.os.opendarwin.webkit. devel (webkit-dev) gtk (webkit-gtk) jobs (webkit-jobs) qt (webkit-qt) user (webkit-help) (user was chosen by the Gmane administrators, presumably to match other projects' groups.) Can we drop the os.opendarwin part? The project formerly known as opendarwin is mostly (http://www.opendarwin.org/) dead. I think gmane.org.webkit would be better. Dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-changes] [52125] trunk/LayoutTests
For anyone else who went digging for the link: http://trac.webkit.org/changeset/52125 :) -eric On Mon, Dec 14, 2009 at 6:42 PM, Adam Roben aro...@apple.com wrote: For predictable failures like these, Darin Adler says the best thing to do is land the expected failure as an expected result, and use a bug to track the fact that it’s wrong. [1] But maybe in the case of tests that time out, it's best to skip them in order to keep the regression tests from slowing down? -Adam 1. http://thread.gmane.org/gmane.os.opendarwin.webkit.devel/10002/focus=10017 ___ 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] questions re: patch length
I have a few questions related to patch length: (1) Do reviewers take patch length into account when considering whether to review a patch? This is useful to know for those who would rather have a short patch reviewed more quickly than wait longer for a longer patch to be reviewed. (2) If reviewers do take patch length into account, what's the best way to handle trivial changes that might inflate patch length (for example moving a large chunk of code or adding an image) -- should such changes be submitted separately? (3) Finally, in people's experience, what is the sweet spot for patch length? (There is an optimization problem here somewhere.) I can add helpful info from responses to the web site where appropriate. Thanks, --Chris ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] questions re: patch length
Personal thoughts: On Dec 14, 2009, at 7:22 PM, Chris Jerdonek wrote: I have a few questions related to patch length: (1) Do reviewers take patch length into account when considering whether to review a patch? This is useful to know for those who would rather have a short patch reviewed more quickly than wait longer for a longer patch to be reviewed. Yes. (2) If reviewers do take patch length into account, what's the best way to handle trivial changes that might inflate patch length (for example moving a large chunk of code or adding an image) -- should such changes be submitted separately? If they are meaningful to do separately (i.e. tree won't be in a ridiculous or broken state) then sure. In particular copying or renaming files or doing large code cleanup is best done separate from substantive changes. It can also help to mention if parts of the patch are mechanical and identify just the most meaningful parts. Another thing that makes it easier for me review is test cases. If I can see exactly what behavior change is intended in the form of a test case, it's easier to evaluate the code changes. This is true even if adding numerous test cases makes the code change overall bigger. (3) Finally, in people's experience, what is the sweet spot for patch length? (There is an optimization problem here somewhere.) I make some effort to break a patch down into the smallest meaningful pieces I can if it seems large, even if I have to do this after the fact. I particularly like to separate preparatory refactorings from actual behavior changes. On the other hand, if some changes really are tied to each other and aren't meaningful separately, I usually bite the bullet. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedScript: next steps and result of offline discussion.
I think that use case has been de-emphasized. However, if we wanted to support it, we'd probably have to say that removeChild of an IFRAME element doesn't cause the unload event to be dispatched. (I'm a bit concerned that that may cause incompatibilities with existing pages.) Then, you'd have to store a reference to the IFRAME element in a global variable, so that you could find it again when the next document is loaded. -Darin On Mon, Dec 14, 2009 at 2:50 PM, Michael Nordman micha...@google.comwrote: How does reparenting across in-place frame navigations work in this scheme? Is a de-parented iframe guaranteed to linger long enough for the new page to get it by name and re-parent it if desired? On Thu, Dec 3, 2009 at 7:01 PM, Dmitry Titov dim...@chromium.org wrote: Hi WebKit, The recent discussion indicated there is a feeling that SharedScript functionality can be achieved by other means that do not require adding new big APIs: changing iframe a bit (so it's internals survive reparenting into another document) and adding single getWindowByName() API. Ian Hickson proposed this idea noting that nothing in the spec prevents iframe from staying alive over the reparenting. Some folks from Google met with folks from Apple to discuss and it appears there is a consensus that we shall remove initial code for SharedScript and instead implement changes for iframe and getWindowByFrame(). This will not cause new API and hopefully won't cause compatibility issues since the only scenario that will behave differently is reparenting of the iframe between documents that is hopefully a rare thing. Perhaps more discussion will be needed to nail details on those. Separately (or related?), we discussed SharedWorkers and the way XHR works in them. It seems a good idea to investigate a shadow document' solution (as Chrome does for worker processes) when a dummy document is created and used to load resources on behalf of the worker. Also we'll try to fix couple of bugs that prevent Workers to be reliable enough. Thanks a lot to all who chimed in and helped to arrive to a good solution to the same issues that SharedScript was trying to solve! :-) Dmitry Titov ___ 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] Sunspider 0.9.1 preview
Hello folks, Over the past few days I made some changes to SunSpider to address some of the more serious issues reported. I focused on only changes that seem to make a significant difference to fairness and validity, so for example I did not remove accidental access to global variables. I also made a small number of harness changes that do not affect results but fix flaws in the harness. We are hesitant to change the SunSpider content or harness much at all, since it's been used for cross-version and cross-brwoser comparisons for so long. But these problems (many originally suggpointed out by Chrome or Mozilla folks) seemed important enough to address. Also, in addition to the patched content set, the original sunspider-0.9 content set is also available to run through the new harness. The most important harness change is greatly reducing the time between tests (as sugested by Mike Belshe) to avoid the negative impact of power management on many systems (both Mac and Windows), and which are most apparent for very fast browsers. I'm deliberately not posting this on the web site yet because I don't want a flood of gawkers testing their browser before enough people have had a chance to review and verify these changes. Harness changes: In-browser SunSpider suffers excessive penalty under power management https://bugs.webkit.org/show_bug.cgi?id=32505 Enable Web-hosted version of SunSpider to handle multiple versions https://bugs.webkit.org/show_bug.cgi?id=32478 Use JSON.parse instead of eval for Web-hosted SunSpider results processing https://bugs.webkit.org/show_bug.cgi?id=32490 Some Browser-hosted SunSpider files are not valid HTML5 https://bugs.webkit.org/show_bug.cgi?id=32536 Make sunspider-0.9.1 the default content set (both command-line and hosted) https://bugs.webkit.org/show_bug.cgi?id=32537 Content changes (in sunspider-0.9.1 suite only; sunspider-0.9 is as originally posted): SunSpider/tests/string-base64.js does not compute a valid base64 encoded string https://bugs.webkit.org/show_bug.cgi?id=16806 sunspider regexp-dna is inaccurate on firefox https://bugs.webkit.org/show_bug.cgi?id=18989 Further changes I'm considering but am unsure about: - Add correctness checking to all tests that don't use random numbers. - Stop using array-like indexing of strings in the base64 test since that doesn't work in IE8 and lower; but it is a standard construct now (ES5), future IE will support it, and it's a useful thing to test. Changes that probably won't be considered until a 2.0 version: - Adding new tests to cover other areas. - Rebalancing the runtime of the existing tests. - Considering different scoring methodology such as bigger-is-better or geometric mean or the like. - Removing use of random numbers from tests that do use them. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
