[webkit-dev] Invitation to connect on LinkedIn
I'd like to add you to my professional network on LinkedIn. - Hw Hw H Student at Nanjing University China Confirm that you know Hw H: https://www.linkedin.com/e/-jnbvix-gshir909-4b/isd/4172438214/B_UjDLgk/?hs=falsetok=30copF8xZDEAU1 -- You are receiving Invitation to Connect emails. Click to unsubscribe: http://www.linkedin.com/e/-jnbvix-gshir909-4b/qxt6X_WQtIhjU098J-t7a9l-QVVLSjg_CRCP9zASYX/goo/webkit-dev%40lists%2Ewebkit%2Eorg/20061/I1440539683_1/?hs=falsetok=1qgikbr7VDEAU1 (c) 2011 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Do you compile with ENABLE_SVG diabled?
When doing ports to various embedded systems we often disable SVG to reduce the size of the resulting library. It would be nice to retain the top level ENABLE_SVG define for this purpose. Thanks, Dan On 09/09/2011 05:42 PM, Eric Seidel wrote: I am interested in removing the ENABLE_SVG define, and all associated sub-defines ENABLE_SVG_ANIMATION ENABLE_SVG_AS_IMAGE ENABLE_SVG_FONTS ENABLE_SVG_FOREIGN_OBJECT ENABLE_SVG_USE SVG is part of HTML5, and all major ports compile and ship with SVG enabled (and have for years). Please let me know if you are compiling with ENABLE_SVG disabled. -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] More ports on nightly.webkit.org?
Do any ports besides the Apple ports produce nightly builds that end-users might be interested in using? If so, it might make sense to expand the offerings on http://nightly.webkit.org/ to include more choices. For example, Linux users might enjoy a nightly build that runs on Linux. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] More ports on nightly.webkit.org?
An excellent idea! - Ryosuke On Mon, Sep 12, 2011 at 11:10 AM, Adam Barth aba...@webkit.org wrote: Do any ports besides the Apple ports produce nightly builds that end-users might be interested in using? If so, it might make sense to expand the offerings on http://nightly.webkit.org/ to include more choices. For example, Linux users might enjoy a nightly build that runs on Linux. 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
Re: [webkit-dev] More ports on nightly.webkit.org?
Also, I often encounter regressions or bugs only reproduce on certain ports but I haven't been able to confirm those bugs because I don't have a luxury of building those ports just to confirm bugs. Providing nightlies for those ports will greatly enhance our ability to narrow down regression windows and triage bugs. - Ryosuke On Mon, Sep 12, 2011 at 11:38 AM, Kaustubh Atrawalkar hwn...@motorola.comwrote: Yes, I second Ryosuke and really would like to support this idea. Not even just end user but developers like us would also like to have sneak in these nightly builds. It will not only help to test the nightly on daily basis but also will help to improve and contribute more. I m ready to help for this in any way possible. - Kaustubh On 12-Sep-2011, at 11:43 PM, Ryosuke Niwa rn...@webkit.org wrote: An excellent idea! - Ryosuke On Mon, Sep 12, 2011 at 11:10 AM, Adam Barth aba...@webkit.org aba...@webkit.org wrote: Do any ports besides the Apple ports produce nightly builds that end-users might be interested in using? If so, it might make sense to expand the offerings on http://nightly.webkit.org/ http://nightly.webkit.org/ to include more choices. For example, Linux users might enjoy a nightly build that runs on Linux. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.orgwebkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] More ports on nightly.webkit.org?
Adam, On 09/12/2011 03:10 PM, Adam Barth wrote: Do any ports besides the Apple ports produce nightly builds that end-users might be interested in using? If so, it might make sense to expand the offerings on http://nightly.webkit.org/ to include more choices. For example, Linux users might enjoy a nightly build that runs on Linux. Excellent. I can provide at least WebKit-EFL/Linux packages. If it's easy to generate packages for other Linux ports as well (GTK and Qt ports I know that are easy to build; never tried Wx and Chromium), I can give a try in writing and maintaining a bot that does that. OTOH, providing binary packages for Linux isn't an easy task. Different packaging standards, ABI differences, etc, makes binary distribution a nightmare: even if a new set of libraries are installed, there is no warranty that the browsers will pick those up or even if it will work at all (not really an issue for nightly builds but annoying nonetheless). If there's an agreement of which Linux distribution should be supported by n.w.o, things will be a lot easier. Cheers, Leandro ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] More ports on nightly.webkit.org?
On Mon, Sep 12, 2011 at 12:18 PM, Leandro Pereira lean...@profusion.mobi wrote: On 09/12/2011 03:10 PM, Adam Barth wrote: Do any ports besides the Apple ports produce nightly builds that end-users might be interested in using? If so, it might make sense to expand the offerings on http://nightly.webkit.org/ to include more choices. For example, Linux users might enjoy a nightly build that runs on Linux. Excellent. I can provide at least WebKit-EFL/Linux packages. If it's easy to generate packages for other Linux ports as well (GTK and Qt ports I know that are easy to build; never tried Wx and Chromium), I can give a try in writing and maintaining a bot that does that. OTOH, providing binary packages for Linux isn't an easy task. Different packaging standards, ABI differences, etc, makes binary distribution a nightmare: even if a new set of libraries are installed, there is no warranty that the browsers will pick those up or even if it will work at all (not really an issue for nightly builds but annoying nonetheless). If there's an agreement of which Linux distribution should be supported by n.w.o, things will be a lot easier. My sense is that each port can make that decision on its own. For example, binary builds of Chrome are available for Debian, Ubuntu, Fedora, and openSUSE. If you wanted to provide binary builds of the EFL port for those or different flavors of Linux, that's up to you. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] More ports on nightly.webkit.org?
12.09.2011, 23:18, Leandro Pereira: OTOH, providing binary packages for Linux isn't an easy task. Different packaging standards, ABI differences, etc, makes binary distribution a nightmare: even if a new set of libraries are installed, there is no warranty that the browsers will pick those up or even if it will work at all (not really an issue for nightly builds but annoying nonetheless). Not really. One can perform a build on CentOS 5 and bundle every library ldd shows with resulting binaries (with exception of libc, libdl, and librt) with application. -- Regards, Konstantin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] More ports on nightly.webkit.org?
On Mon, Sep 12, 2011 at 11:57 AM, Ryosuke Niwa rn...@webkit.org wrote: Also, I often encounter regressions or bugs only reproduce on certain ports but I haven't been able to confirm those bugs because I don't have a luxury of building those ports just to confirm bugs. Providing nightlies for those ports will greatly enhance our ability to narrow down regression windows and triage bugs. Massive point. - Ryosuke On Mon, Sep 12, 2011 at 11:38 AM, Kaustubh Atrawalkar hwn...@motorola.com wrote: Yes, I second Ryosuke and really would like to support this idea. Not even just end user but developers like us would also like to have sneak in these nightly builds. It will not only help to test the nightly on daily basis but also will help to improve and contribute more. I m ready to help for this in any way possible. - Kaustubh On 12-Sep-2011, at 11:43 PM, Ryosuke Niwa rn...@webkit.org wrote: An excellent idea! - Ryosuke On Mon, Sep 12, 2011 at 11:10 AM, Adam Barth aba...@webkit.org aba...@webkit.org wrote: Do any ports besides the Apple ports produce nightly builds that end-users might be interested in using? If so, it might make sense to expand the offerings on http://nightly.webkit.org/ http://nightly.webkit.org/ to include more choices. For example, Linux users might enjoy a nightly build that runs on Linux. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.orgwebkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev 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 -- *Sencha* Jarred Nicholls, Senior Software Architect @jarrednicholls http://twitter.com/jarrednicholls ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Committing EFL baselines
Hi. What's the preferred way to commit a ton of baselines for a port that currently has none? On our internal EFL tree, there is about 125MB of baselines for both pixel and text tests. Unfortunately we were unable to share our baselines with similar ports, due to slight differences in results. This is pretty much unreviewable, so I pretend to commit this directly, in batches (one commit per toplevel directory in LayoutTests/platform/efl) in the next weeks. Any objections or suggestions? Cheers, Leandro ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Committing EFL baselines
On Mon, Sep 12, 2011 at 1:32 PM, Leandro Pereira lean...@profusion.mobiwrote: Hi. What's the preferred way to commit a ton of baselines for a port that currently has none? On our internal EFL tree, there is about 125MB of baselines for both pixel and text tests. Unfortunately we were unable to share our baselines with similar ports, due to slight differences in results. What are differences you're seeing? This is pretty much unreviewable, so I pretend to commit this directly, in batches (one commit per toplevel directory in LayoutTests/platform/efl) in the next weeks. Any objections or suggestions? It'll be nice if we could spend some time analyzing the differences between EFL and other ports to minimize the size of patch first. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] A not-quite baked proposal for moving pixel baselines out of trunk
Leandro's recent message reminded me that there was some discussion on this list about the burden caused by storing and maintaining pixel baselines for an ever-growing list of configurations. I've been working on a proposal for moving pixel baselines to a branch so that they don't bother most folks. Unfortunately, I haven't been able to work out all the details yet. Here's a somewhat rough, work-in-progress proposal. If you like this approach, I can spend more time trying to solve the remaining problems. == Motivation == Maintaining pixel test results in svn.webkit.org for the various Chromium configuration imposes a number of costs on the WebKit community: All members of the community need to store these results locally when they create a checkout of WebKit. Updating the pixel results creates churn in the project that increases the time required to update a working copy and makes it more difficult to understand what is actually changing in the project. As the Chromium port grows in complexity, there is pressure from the Chromium project to expand the number of test configurations, increasing these costs on the WebKit community. == Proposal (Work-in-progress) == One option is to stop running pixel test altogether, but that decreases test coverage and costs correctness. Another possibility is to store the pixel results in a location where they are largely invisible to the rest of the WebKit community. For example, we could store the pixel results for chromium-linux the following location: http://svn.webkit.org/repository/webkit/PixelResults/chromium-linux Chromium contributors could then use gclient and DEPS to map these results into their working copies and non-chromium contributors could safely ignore any changes in the PixelResults “branch”. FIXME: What about non-platform specific results? == Problems == The main reason this proposal is half-baked is I haven't quite been able to work out how folks can do some common operations: 1) Land patch with expected image failures (+ revert) 2) Land patch with new image baselines (+ revert) 3) Land new baselines Because the pixel results and trunk are in the same SVN repo, we should be able to do these things atomically, but dealing with the sparse checkout is kind of tricky. Another big question mark is how this would work for contributors who use git. When git mirrors an SVN repro, it only mirrors trunk, so the PixelResults directory wouldn't exist in the git version of the repository. Thoughts? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Committing EFL baselines
On Mon, Sep 12, 2011 at 1:48 PM, Peter Kasting pkast...@chromium.orgwrote: On Mon, Sep 12, 2011 at 1:36 PM, Ryosuke Niwa rn...@webkit.org wrote: This is pretty much unreviewable, so I pretend to commit this directly, in batches (one commit per toplevel directory in LayoutTests/platform/efl) in the next weeks. Any objections or suggestions? It'll be nice if we could spend some time analyzing the differences between EFL and other ports to minimize the size of patch first. In particular, if we have pixel tests that don't need to be pixel tests at all, or font rendering differences due to explanatory text that could be moved to an HTML comment inside the test itself, we can obviate the need for port-specific baselines in many of those cases (and eliminate more baselines from ports already in the tree, and reduce the burden on other ports that want to run pixel tests, and reduce the maintenance cost of changing the tests). Are y'all suggesting that efl port should do these items (converting pixel tests to non-pixel tests) before committing their baselines? dave PS fwiw, at one point, I did some work to figure out which tests were changing most often to see where people would get the most return on their investment and to my memory many tests with a high churn rate were svg (which seem like they would be harder to convert to a non-pixel test format). PK ___ 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] Committing EFL baselines
On Mon, Sep 12, 2011 at 1:56 PM, David Levin le...@chromium.org wrote: On Mon, Sep 12, 2011 at 1:48 PM, Peter Kasting pkast...@chromium.orgwrote: On Mon, Sep 12, 2011 at 1:36 PM, Ryosuke Niwa rn...@webkit.org wrote: This is pretty much unreviewable, so I pretend to commit this directly, in batches (one commit per toplevel directory in LayoutTests/platform/efl) in the next weeks. Any objections or suggestions? It'll be nice if we could spend some time analyzing the differences between EFL and other ports to minimize the size of patch first. In particular, if we have pixel tests that don't need to be pixel tests at all, or font rendering differences due to explanatory text that could be moved to an HTML comment inside the test itself, we can obviate the need for port-specific baselines in many of those cases (and eliminate more baselines from ports already in the tree, and reduce the burden on other ports that want to run pixel tests, and reduce the maintenance cost of changing the tests). Are y'all suggesting that efl port should do these items (converting pixel tests to non-pixel tests) before committing their baselines? No. But in general, we try to match DRT's behavior to that of Mac port to avoid adding redundant baselines so EFL port should do the same. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Committing EFL baselines
On Mon, Sep 12, 2011 at 1:56 PM, David Levin le...@chromium.org wrote: On Mon, Sep 12, 2011 at 1:48 PM, Peter Kasting pkast...@chromium.orgwrote: In particular, if we have pixel tests that don't need to be pixel tests at all, or font rendering differences due to explanatory text that could be moved to an HTML comment inside the test itself, we can obviate the need for port-specific baselines in many of those cases (and eliminate more baselines from ports already in the tree, and reduce the burden on other ports that want to run pixel tests, and reduce the maintenance cost of changing the tests). Are y'all suggesting that efl port should do these items (converting pixel tests to non-pixel tests) before committing their baselines? I don't think it's fair to force the EFL folks to do all this. I do think all ports would benefit from it and all ports should be spending some effort on this kind of thing. Inasmuch as there is an opportunity here for doing this work to minimize the landing cost for the EFL baselines, I'm raising this so that those folks can keep the option in mind and make use of it opportunistically. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Color profiles in expected.png files
On Fri, Sep 9, 2011 at 7:21 PM, Simon Fraser simon.fra...@apple.com wrote: I think we should be consistent about color profiles, and in a way that doesn't break pixel tests. Does anyone want to vote one way or the other? I suspect no profiles is the only way that will work across both ports that handle embedded color profiles and ports that do not. (AFAIK some Chromium ports currently do not.) PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Committing EFL baselines
On 09/12/2011 05:36 PM, Ryosuke Niwa wrote: On our internal EFL tree, there is about 125MB of baselines for both pixel and text tests. Unfortunately we were unable to share our baselines with similar ports, due to slight differences in results. What are differences you're seeing? Most differences are because the EFL port doesn't change the viewport size because of the scrollbar: it is drawn on top of the content on the EFL port by default. So there is a little more room horizontally, and then text results are slightly different from GTK+'s (which uses the same font backends, for instance). In those tests that only draws colored rectangles, the render tree is pretty much the same as any other port's. However, in these tests, the pixel results are rendered with colors slightly different from the expected. Almost no difference to the naked eye. I suspect either some rounding problems inside Cairo, or wrong color profile. Leandro ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Committing EFL baselines
On Mon, Sep 12, 2011 at 2:50 PM, Leandro Pereira lean...@profusion.mobiwrote: Most differences are because the EFL port doesn't change the viewport size because of the scrollbar: it is drawn on top of the content on the EFL port by default. So there is a little more room horizontally, and then text results are slightly different from GTK+'s (which uses the same font backends, for instance). In those tests that only draws colored rectangles, the render tree is pretty much the same as any other port's. However, in these tests, the pixel results are rendered with colors slightly different from the expected. Almost no difference to the naked eye. I suspect either some rounding problems inside Cairo, or wrong color profile. Chromium port has made a significant effort into matching scrollbar/color with Mac port to mitigate this issue. Maybe you can talk to one of our friendly contributors and get some help in reducing the number of baselines you need to check in. I don't intend to claim that you're obligated to do this but if you check in a lot of port-specific baselines, then you're very likely end up having to rebaseline hundreds of tests each day to catch up with new changes landed in trunk. This is a very tedious job and people from other ports spend a significant engineering time into this. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing style scoped
Ryosuke Niwa wrote: Why do diverge? It seems like we should at least prefix the attribute with webkit in the case spec changes in the future. See above linked discussion for details. In the end we felt limiting the selector matching to the scope is more natural, and - with the proposed exception providued by :root and :scope - is more flexible. However, naming the attribute 'webkit-scoped' may certainly be a good idea. Yes, please use webkitscoped (no - since this is content attribute?). The spec requests that vendor-specific attributes take names of the form x-vendor-feature: http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#extensibility So x-webkit-scoped would be the way to go. Ted ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] make-script-test-wrappers not being maintained
On Sep 8, 2011, at 11:15 AM, Eric Seidel wrote: It seems the sucessfullyParsed question could also be answered by some intelligent onerror handler added to the right script tag. The successfullyParsed thing was originally added to benefit JS tests running in the browser. If you get a bunch of passes and then an exception which prevents further output, you wouldn't think that everything passed solely because the output is truncated. If it's possible to achieve this with onerror, and if this technique works cross-browser (an important use case for assertion-style layout tests is to load them in other browsers), then that would be fine by me. Last I heard, Opera didn't support onerror properly, but this may have changed. - Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing style scoped
On Sep 8, 2011, at 2:28 PM, Roland Steiner wrote: Hi all, After several discussions on the whatwg@ mailing list and others, we would like to go forward with adding style scoped to WebKit. Overview: Style rules within style scoped only apply to the parent element of style scoped (the scoping element), as well as descendants of it. Any other nodes are unaffected. This allows authors to style specific parts of a page without requiring ID prefixes. It also has potential performance benefits, as scoped rules do not need to be evaluated outside their scope. As per discussion on http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-June/032056.html, our implementation would diverge from the current HTML5 spec (http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-style-element) in that we would match selectors only up to, and including, the scoping element. E.g.,: It sounds like there wasn't consensus to make this spec change. In particular, Hixie's last comments seemed to disagree with the proposed change. My preferences would be: 1. Implement what the spec says rather than diverging. 2. Get the spec actually changed, or at least agreement in principle to change the spec, then implement the proposed behavior. 3. Make sure to webkit prefix it and maybe even call the attribute something other than scoped if we are not confident of the spec change coming through. It's definitely *not* ok to call the attribute scoped but not match what the spec says, in my opinion. I would strongly prefer #1 or #2 to #3. I don't have any particular opinion on the substantive issue, but I don't think we should just diverge without agreement from others. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] A not-quite baked proposal for moving pixel baselines out of trunk
On Mon, Sep 12, 2011 at 1:48 PM, Adam Barth aba...@webkit.org wrote: Leandro's recent message reminded me that there was some discussion on this list about the burden caused by storing and maintaining pixel baselines for an ever-growing list of configurations. I've been working on a proposal for moving pixel baselines to a branch so that they don't bother most folks. Unfortunately, I haven't been able to work out all the details yet. Here's a somewhat rough, work-in-progress proposal. If you like this approach, I can spend more time trying to solve the remaining problems. == Motivation == Maintaining pixel test results in svn.webkit.org for the various Chromium configuration imposes a number of costs on the WebKit community: All members of the community need to store these results locally when they create a checkout of WebKit. Updating the pixel results creates churn in the project that increases the time required to update a working copy and makes it more difficult to understand what is actually changing in the project. As the Chromium port grows in complexity, there is pressure from the Chromium project to expand the number of test configurations, increasing these costs on the WebKit community. == Proposal (Work-in-progress) == One option is to stop running pixel test altogether, but that decreases test coverage and costs correctness. Another possibility is to store the pixel results in a location where they are largely invisible to the rest of the WebKit community. For example, we could store the pixel results for chromium-linux the following location: http://svn.webkit.org/repository/webkit/PixelResults/chromium-linux Chromium contributors could then use gclient and DEPS to map these results into their working copies and non-chromium contributors could safely ignore any changes in the PixelResults “branch”. FIXME: What about non-platform specific results? == Problems == The main reason this proposal is half-baked is I haven't quite been able to work out how folks can do some common operations: 1) Land patch with expected image failures (+ revert) 2) Land patch with new image baselines (+ revert) 3) Land new baselines Because the pixel results and trunk are in the same SVN repo, we should be able to do these things atomically, but dealing with the sparse checkout is kind of tricky. Another big question mark is how this would work for contributors who use git. When git mirrors an SVN repro, it only mirrors trunk, so the PixelResults directory wouldn't exist in the git version of the repository. git-svn would be the fallback - I'd rather take razor blades to my eyes. But this is a noble effort in general, thanks. Do we need to do anything to alleviate history in the git mirror? I'd love to clone 25MB and not 2.1GB. Thoughts? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- *Sencha* Jarred Nicholls, Senior Software Architect @jarrednicholls http://twitter.com/jarrednicholls ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] A not-quite baked proposal for moving pixel baselines out of trunk
On Mon, Sep 12, 2011 at 4:11 PM, Jarred Nicholls jar...@sencha.com wrote: On Mon, Sep 12, 2011 at 1:48 PM, Adam Barth aba...@webkit.org wrote: Leandro's recent message reminded me that there was some discussion on this list about the burden caused by storing and maintaining pixel baselines for an ever-growing list of configurations. I've been working on a proposal for moving pixel baselines to a branch so that they don't bother most folks. Unfortunately, I haven't been able to work out all the details yet. Here's a somewhat rough, work-in-progress proposal. If you like this approach, I can spend more time trying to solve the remaining problems. == Motivation == Maintaining pixel test results in svn.webkit.org for the various Chromium configuration imposes a number of costs on the WebKit community: All members of the community need to store these results locally when they create a checkout of WebKit. Updating the pixel results creates churn in the project that increases the time required to update a working copy and makes it more difficult to understand what is actually changing in the project. As the Chromium port grows in complexity, there is pressure from the Chromium project to expand the number of test configurations, increasing these costs on the WebKit community. == Proposal (Work-in-progress) == One option is to stop running pixel test altogether, but that decreases test coverage and costs correctness. Another possibility is to store the pixel results in a location where they are largely invisible to the rest of the WebKit community. For example, we could store the pixel results for chromium-linux the following location: http://svn.webkit.org/repository/webkit/PixelResults/chromium-linux Chromium contributors could then use gclient and DEPS to map these results into their working copies and non-chromium contributors could safely ignore any changes in the PixelResults “branch”. FIXME: What about non-platform specific results? == Problems == The main reason this proposal is half-baked is I haven't quite been able to work out how folks can do some common operations: 1) Land patch with expected image failures (+ revert) 2) Land patch with new image baselines (+ revert) 3) Land new baselines Because the pixel results and trunk are in the same SVN repo, we should be able to do these things atomically, but dealing with the sparse checkout is kind of tricky. Another big question mark is how this would work for contributors who use git. When git mirrors an SVN repro, it only mirrors trunk, so the PixelResults directory wouldn't exist in the git version of the repository. git-svn would be the fallback - I'd rather take razor blades to my eyes. But this is a noble effort in general, thanks. Do we need to do anything to alleviate history in the git mirror? I'd love to clone 25MB and not 2.1GB. I'm not a git expert, so I'm not sure if there's any way to repair the sins of the past (e.g., with filter-branch) while still keeping git-svn working. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing style scoped
On Mon, Sep 12, 2011 at 4:11 PM, Maciej Stachowiak m...@apple.com wrote: On Sep 8, 2011, at 2:28 PM, Roland Steiner wrote: Hi all, After several discussions on the whatwg@ mailing list and others, we would like to go forward with adding style scoped to WebKit. Overview: Style rules within style scoped only apply to the parent element of style scoped (the scoping element), as well as descendants of it. Any other nodes are unaffected. This allows authors to style specific parts of a page without requiring ID prefixes. It also has potential performance benefits, as scoped rules do not need to be evaluated outside their scope. As per discussion on http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-June/032056.html, our implementation would diverge from the current HTML5 spec (http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-style-element) in that we would match selectors only up to, and including, the scoping element. E.g.,: It sounds like there wasn't consensus to make this spec change. In particular, Hixie's last comments seemed to disagree with the proposed change. My preferences would be: 1. Implement what the spec says rather than diverging. 2. Get the spec actually changed, or at least agreement in principle to change the spec, then implement the proposed behavior. 3. Make sure to webkit prefix it and maybe even call the attribute something other than scoped if we are not confident of the spec change coming through. It's definitely *not* ok to call the attribute scoped but not match what the spec says, in my opinion. I would strongly prefer #1 or #2 to #3. I don't have any particular opinion on the substantive issue, but I don't think we should just diverge without agreement from others. Yeah. You're right. We should get Hixie to change the spec. I don't think we should implement currently spec'd behavior or change the name. That last option sounds exceptionally bad. Roland, can you post on that thread and request the spec change? :DG Regards, Maciej ___ 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] run-bindings-tests
On Sep 8, 2011, at 12:25 PM, Darin Adler wrote: On Sep 8, 2011, at 11:49 AM, Alexey Proskuryakov wrote: As discussed on IRC, I do not think that bots should run this test at all. It has a non-trivial maintenance cost, but provides very little benefit. Even the time spent by multiple engineers on IRC today discussing bot complaints is likely more than the test could save in the lifetime of the project, at my guesstimate. I find the bindings tests quite helpful. Because the perl script is so hard to read, it’s the changes in bindings script test results that I look at when reviewing changes to the bindings scripts. The fact that the results are checked in helps me review patches. It would be better to plug them in to the testing machinery in a better way. I don’t think contributors should have to learn how to run different types of commands. Notwithstanding all the later discussion, I think run-bindings-tests would still be more effective as a build step that updates a source file rather than a test step. Recompiling after changing the bindings generator would then regenerate this file, and the diffs would be present in uploaded patches (as well as being obtainable to developers working locally by using svn diff or git diff respectively). That way, it's much harder to do it wrong and cause bot redness downstream. It's possible that this way you could cause bindings changes unintentionally, but presumably you and your reviewer will spot these when looking at the patch. It seems to me we shouldn't require an extra manual step to say I really meant to change the text of the generated bindings. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] run-bindings-tests
On Sep 12, 2011, at 4:23 PM, Maciej Stachowiak wrote: Notwithstanding all the later discussion, I think run-bindings-tests would still be more effective as a build step that updates a source file rather than a test step. I see, a build step that updates a checked-in source file. Sounds like a great idea to me. I did not see that proposal earlier! -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] A not-quite baked proposal for moving pixel baselines out of trunk
On Mon, Sep 12, 2011 at 4:11 PM, Jarred Nicholls jar...@sencha.com wrote: git-svn would be the fallback - I'd rather take razor blades to my eyes. But this is a noble effort in general, thanks. Do we need to do anything to alleviate history in the git mirror? I'd love to clone 25MB and not 2.1GB. Once the baselines are out, git clone --depth 1. I urge you to not spend much too much time ratholing this into git questions; I think the first problems Adam listed under Problems are the real killers, and without a good answer for those the whole idea is a nonstarter. (I would love to solve this too, I just also don't see a good way to handle it.) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Do you maintain OS(WINCE)?
Hi folks. It looks like another build variant that relies on threads not existing in WebKit and JavaScriptCore is OS(WINCE). Do you maintain OS(WINCE)? If so, are you interested in implemented JavaScriptCore threading primitives for it? If nobody maintains OS(WINCE), I'm inclined to remove it in a follow-up patch. Thanks, Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Mouse Lock API
A Mouse Lock API has been under discussion on the W3 public-webapps list Mouse Lock(1) and earlier Mouse Capture for Canvas(2). The primary goal is to enable use cases such as first person perspective 3D applications. This is done by providing scripted access to mouse movement data while locking the target of mouse events to a single element and removing the cursor from view. I have been working to formalize the discussions into a draft specification: http://goo.gl/9G8pd, and have a work in progress prototype for WebKit | Chrome. I will publish a WIP patch when it is ready for more eyes. It will be developed behind a compile (and runtime) time flag. I'd like to invite any specification discussion to the Mouse Lock thread (1), and WebKit implementation discussion here. Cheers, -Vince -- 1. http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/thread.html#msg960 2. http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/thread.html#msg437 W3 issue: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9557 Firefox issue: https://bugzilla.mozilla.org/show_bug.cgi?id=633602 Chrome issue: http://code.google.com/p/chromium/issues/detail?id=72754 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Disable Javascript security warnings?
Hey all, I'm working on a web scraper that embeds WebKit directly (via pyWebKitGTK if it matters, though I don't think my question is specific to that library). I'm trying to extract image metadata (domains, dimensions, location on the page, etc) from a page, including any iframes that are embedded there. Because WebKit already knows everything about the data I want (image dimensions, position on page), I'm extracting content by executing javascript via the webkit_web_view_execute_script call described here: http://webkitgtk.org/reference/webkitgtk-webkitwebview.html#webkit-web-view-execute-script My javascript works when the iframes are on the same domain, but fails (obviously) when they're not. How can I disable the Unsafe JavaScript attempt to access frame with URL http://www.google.com/ from frame with URL http://10.0.0.50/js_test.html. Domains, protocols and ports must match. error message? I've come across the WebKitSecurityOrigin object and I've been able to extract the host/port/protocol of my current page, but I haven't found a way to spoof this mechanism… I know too that Chrome has the --disable-web-security flag, but I can't quite put my finger on what I need to do to replicate this functionality when working with WebKit directly. Can anyone offer a pointer or suggestion? Thanks so much! --Rob ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Disable Javascript security warnings?
From your javascript, perhaps you can set the referring URL in the HTTP Headers of the request( to get IFrames) to http://www.google.com;, or whichever URL you are requesting the frames for? You will have to create your own XHR object for the HTTP Request. Thanks, -Kavitha From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Rob Crowell Sent: Monday, September 12, 2011 6:42 PM To: webkit-dev@lists.webkit.org Subject: [webkit-dev] Disable Javascript security warnings? Hey all, I'm working on a web scraper that embeds WebKit directly (via pyWebKitGTK if it matters, though I don't think my question is specific to that library). I'm trying to extract image metadata (domains, dimensions, location on the page, etc) from a page, including any iframes that are embedded there. Because WebKit already knows everything about the data I want (image dimensions, position on page), I'm extracting content by executing javascript via the webkit_web_view_execute_script call described here: http://webkitgtk.org/reference/webkitgtk-webkitwebview.html#webkit-web-view-execute-script My javascript works when the iframes are on the same domain, but fails (obviously) when they're not. How can I disable the Unsafe JavaScript attempt to access frame with URL http://www.google.com/ from frame with URL http://10.0.0.50/js_test.html. Domains, protocols and ports must match. error message? I've come across the WebKitSecurityOrigin object and I've been able to extract the host/port/protocol of my current page, but I haven't found a way to spoof this mechanism... I know too that Chrome has the --disable-web-security flag, but I can't quite put my finger on what I need to do to replicate this functionality when working with WebKit directly. Can anyone offer a pointer or suggestion? Thanks so much! --Rob ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Disable Javascript security warnings?
There is a setting to disable security. I'm not sure whether it is exposed in the API you're using. Adam On Sep 12, 2011 7:13 PM, Devara, Kavitha kdev...@quicinc.com wrote: From your javascript, perhaps you can set the referring URL in the HTTP Headers of the request( to get IFrames) to http://www.google.com;, or whichever URL you are requesting the frames for? You will have to create your own XHR object for the HTTP Request. Thanks, -Kavitha From: webkit-dev-boun...@lists.webkit.org [mailto: webkit-dev-boun...@lists.webkit.org] On Behalf Of Rob Crowell Sent: Monday, September 12, 2011 6:42 PM To: webkit-dev@lists.webkit.org Subject: [webkit-dev] Disable Javascript security warnings? Hey all, I'm working on a web scraper that embeds WebKit directly (via pyWebKitGTK if it matters, though I don't think my question is specific to that library). I'm trying to extract image metadata (domains, dimensions, location on the page, etc) from a page, including any iframes that are embedded there. Because WebKit already knows everything about the data I want (image dimensions, position on page), I'm extracting content by executing javascript via the webkit_web_view_execute_script call described here: http://webkitgtk.org/reference/webkitgtk-webkitwebview.html#webkit-web-view-execute-script My javascript works when the iframes are on the same domain, but fails (obviously) when they're not. How can I disable the Unsafe JavaScript attempt to access frame with URL http://www.google.com/ from frame with URL http://10.0.0.50/js_test.html. Domains, protocols and ports must match. error message? I've come across the WebKitSecurityOrigin object and I've been able to extract the host/port/protocol of my current page, but I haven't found a way to spoof this mechanism... I know too that Chrome has the --disable-web-security flag, but I can't quite put my finger on what I need to do to replicate this functionality when working with WebKit directly. Can anyone offer a pointer or suggestion? Thanks so much! --Rob ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
