[webkit-dev] Removing support for the -khtml- (and -apple-?) vendor prefixes
Good day, While going through WebCore for some CSS research I'm currently doing, I came across a piece of code[1] which translates all -khtml- and -apple- vendor-prefixes to -webkit-. This effectively means -apple-transform and -khtml-transform can both be used instead of -webkit-transform. I am unaware of the rationales behind the apple vendor-prefix, but I'd like to propose removing support for the KHTML-prefix. My main argument for this is that WebKit and KHTML are, in my opinion, two separate engines by two separate vendors. The port occurred eight years ago, and code in both projects has changed significantly ever since. When Microsoft announced support for -webkit-text-size-adjust in IE Mobile it was argued that browsers should not implement properties with prefixes belonging to other vendors, which seems to be exactly what WebKit is doing with the KHTML prefix. I understand the history of supporting -khtml-, and have heard from the KHTML project that they implement the -webkit- prefix as well. However, considering that WebKit has grown significantly in the past few years and that all code changes basically made KHTML and WebKit two individual rendering engines, with individual CSS support, I believe it would be appropriate for support to be dropped. Regards, Peter Beverloo http://peter.sh/ [1] http://trac.webkit.org/browser/trunk/WebCore/css/CSSParser.cpp#L5583 [2] http://blogs.msdn.com/b/iemobile/archive/2010/05/10/javascript-and-css-changes-in-ie-mobile-for-windows-phone-7.aspx ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Removing support for the -khtml- (and -apple-?) vendor prefixes
On Mon, Jul 12, 2010 at 18:00, Ryosuke Niwa rn...@webkit.org wrote: While converting all -khtml- properties to -webkit- may not be appropriate because there could be incompatible implementation of certain property, there are properties starting with -khtml- that are supposed to be supported by WebKit. See bugs such as https://bugs.webkit.org/show_bug.cgi?id=11825. Not supporting these will be a burden for some Web developers as they need to add both -khtml- and -webkit- to specify one property. Best, Ryosuke Niwa On Mon, Jul 12, 2010 at 1:53 AM, Peter Beverloo pe...@lvp-media.com wrote: Good day, While going through WebCore for some CSS research I'm currently doing, I came across a piece of code[1] which translates all -khtml- and -apple- vendor-prefixes to -webkit-. This effectively means -apple-transform and -khtml-transform can both be used instead of -webkit-transform. I am unaware of the rationales behind the apple vendor-prefix, but I'd like to propose removing support for the KHTML-prefix. My main argument for this is that WebKit and KHTML are, in my opinion, two separate engines by two separate vendors. The port occurred eight years ago, and code in both projects has changed significantly ever since. When Microsoft announced support for -webkit-text-size-adjust in IE Mobile it was argued that browsers should not implement properties with prefixes belonging to other vendors, which seems to be exactly what WebKit is doing with the KHTML prefix. I understand the history of supporting -khtml-, and have heard from the KHTML project that they implement the -webkit- prefix as well. However, considering that WebKit has grown significantly in the past few years and that all code changes basically made KHTML and WebKit two individual rendering engines, with individual CSS support, I believe it would be appropriate for support to be dropped. Regards, Peter Beverloo http://peter.sh/ [1] http://trac.webkit.org/browser/trunk/WebCore/css/CSSParser.cpp#L5583 [2] http://blogs.msdn.com/b/iemobile/archive/2010/05/10/javascript-and-css-changes-in-ie-mobile-for-windows-phone-7.aspx ___ 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 I decided to take this issue to the mailing lists before posting a patch for such reasons. The Apple documentation which is referred to[1] in that bug has been updated to use WebKit's own vendor prefix, so I suspect the impact of removing -khtml- will be rather small. After all, that regression happened about four years ago. I will upload a patch within a few hours. Regards, Peter Beverloo http://peter.sh/ [1] http://developer.apple.com/mac/library/documentation/AppleApplications/Conceptual/SafariJSProgTopics/Tasks/DragAndDrop.html ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Removing support for the -khtml- (and -apple-?) vendor prefixes
Right now WebKit has by far the most prefixed elements[1], a significant part of which have not been standardized/drafted yet. Keeping the translation for all properties active practically triples the amount of supported vendor-specific CSS extensions, which cannot be desirable. I'm not opposed to the idea of limiting the supported properties for these prefixes to a certain subset, but my preference would be to only support behavioral properties as -webkit-binding, -webkit-font-smoothing, -webkit-highlight and -webkit-user-(drag|modify|select). In the same piece of code, prefixed versions of border-radixes and opacity are still supported as well. Although I think the latter of which could be removed as well, considering Safari 1.1 got released in 2003. Regards, Peter Beverloo http://peter.sh/ [1] http://peter.sh/examples/?/css/vendor-prefix.html [2] https://bugs.webkit.org/show_bug.cgi?id=42093 On Mon, Jul 12, 2010 at 19:09, Maciej Stachowiak m...@apple.com wrote: The reason for these is historical. Originally, we didn't use a separate vendor prefix for WebKit, just -khtml. Later we changed to -apple. Eventually we realized WebKit would not be an Apple-specific project forever, so we switched to -webkit. The main risk to removing the old prefixes is that some older WebKit-specific content authored against them will break. I'm not sure the code cleanup benefits outweigh the risk of breaking content. If we want to phase out support for these older prefixes, what I'd propose as a first step is supporting the legacy prefixes for old properties but not for any new ones. Regards, Maciej On Jul 12, 2010, at 1:53 AM, Peter Beverloo wrote: Good day, While going through WebCore for some CSS research I'm currently doing, I came across a piece of code[1] which translates all -khtml- and -apple- vendor-prefixes to -webkit-. This effectively means -apple-transform and -khtml-transform can both be used instead of -webkit-transform. I am unaware of the rationales behind the apple vendor-prefix, but I'd like to propose removing support for the KHTML-prefix. My main argument for this is that WebKit and KHTML are, in my opinion, two separate engines by two separate vendors. The port occurred eight years ago, and code in both projects has changed significantly ever since. When Microsoft announced support for -webkit-text-size-adjust in IE Mobile it was argued that browsers should not implement properties with prefixes belonging to other vendors, which seems to be exactly what WebKit is doing with the KHTML prefix. I understand the history of supporting -khtml-, and have heard from the KHTML project that they implement the -webkit- prefix as well. However, considering that WebKit has grown significantly in the past few years and that all code changes basically made KHTML and WebKit two individual rendering engines, with individual CSS support, I believe it would be appropriate for support to be dropped. Regards, Peter Beverloo http://peter.sh/ [1] http://trac.webkit.org/browser/trunk/WebCore/css/CSSParser.cpp#L5583 [2] http://blogs.msdn.com/b/iemobile/archive/2010/05/10/javascript-and-css-changes-in-ie-mobile-for-windows-phone-7.aspx ___ 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] Removing support for the -khtml- (and -apple-?) vendor prefixes
Excuse me, I forgot to note the new bug + patch in my previous mail, although it was listed in the references. https://bugs.webkit.org/show_bug.cgi?id=42093 Regards, Peter Beverloo http://peter.sh/ On Mon, Jul 12, 2010 at 17:26, Eric Seidel e...@webkit.org wrote: Please post a patch: http://webkit.org/coding/contributing.html On Mon, Jul 12, 2010 at 8:25 AM, Eric Seidel e...@webkit.org wrote: Sounds like an easy patch to post. I'm in favor of removing this support. Reducing the number of non-standard CSS properties we support seems like a good thing. -eric On Mon, Jul 12, 2010 at 1:53 AM, Peter Beverloo pe...@lvp-media.com wrote: Good day, While going through WebCore for some CSS research I'm currently doing, I came across a piece of code[1] which translates all -khtml- and -apple- vendor-prefixes to -webkit-. This effectively means -apple-transform and -khtml-transform can both be used instead of -webkit-transform. I am unaware of the rationales behind the apple vendor-prefix, but I'd like to propose removing support for the KHTML-prefix. My main argument for this is that WebKit and KHTML are, in my opinion, two separate engines by two separate vendors. The port occurred eight years ago, and code in both projects has changed significantly ever since. When Microsoft announced support for -webkit-text-size-adjust in IE Mobile it was argued that browsers should not implement properties with prefixes belonging to other vendors, which seems to be exactly what WebKit is doing with the KHTML prefix. I understand the history of supporting -khtml-, and have heard from the KHTML project that they implement the -webkit- prefix as well. However, considering that WebKit has grown significantly in the past few years and that all code changes basically made KHTML and WebKit two individual rendering engines, with individual CSS support, I believe it would be appropriate for support to be dropped. Regards, Peter Beverloo http://peter.sh/ [1] http://trac.webkit.org/browser/trunk/WebCore/css/CSSParser.cpp#L5583 [2] http://blogs.msdn.com/b/iemobile/archive/2010/05/10/javascript-and-css-changes-in-ie-mobile-for-windows-phone-7.aspx ___ 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] Removing support for the -khtml- (and -apple-?) vendor prefixes
Good day, While going through WebCore for some CSS research I'm currently doing, I came across a piece of code[1] which translates all -khtml- and -apple- vendor-prefixes to -webkit-. This effectively means -apple-transform and -khtml-transform can both be used instead of -webkit-transform. I am unaware of the rationales behind the apple vendor-prefix, but I'd like to propose removing support for the KHTML-prefix. My main argument for this is that WebKit and KHTML are, in my opinion, two separate engines by two separate vendors. The port occurred eight years ago, and code in both projects has changed significantly ever since. When Microsoft announced support for -webkit-text-size-adjust in IE Mobile it was argued that browsers should not implement properties with prefixes belonging to other vendors, which seems to be exactly what WebKit is doing with the KHTML prefix. I understand the history of supporting -khtml-, and I've heard from the KHTML project that they implement the -webkit- prefix as well. However, considering that WebKit has grown significantly in the past few years and that all code changes basically made KHTML and WebKit two individual rendering engines with individual CSS support, I believe it would be appropriate for support to be dropped. Regards, Peter Beverloo http://peter.sh/ [1] http://trac.webkit.org/browser/trunk/WebCore/css/CSSParser.cpp#L5583 [2] http://blogs.msdn.com/b/iemobile/archive/2010/05/10/javascript-and-css-changes-in-ie-mobile-for-windows-phone-7.aspx ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Removing support for the -khtml- (and -apple-?) vendor prefixes
On Mon, Jul 12, 2010 at 22:28, David Hyatt hy...@apple.com wrote: On Jul 12, 2010, at 12:09 PM, Maciej Stachowiak wrote: The reason for these is historical. Originally, we didn't use a separate vendor prefix for WebKit, just -khtml. Later we changed to -apple. That's not quite right. Originally we just had -khtml- for CSS extensions, and then we used -apple- for features that we were Apple-specific, i.e., that we knew nobody else would care about. Those features include Dashboard regions and Safari RSS line clamping). Eventually we just decided to merge both into a common prefix, but we wanted to keep the old property names working for compatibility. It was convenient to just map both to -webkit- rather than actually checking the specific property names and only supporting either -khtml- or -apple-. My recommendation would be as follows: (1) Drop support for -khtml- completely. (2) Continue to support -apple- for -apple-dashboard-region and -apple-line-clamp only. dave (hy...@apple.com) I have submitted a patch[1] following your recommendations. Regards, Peter Beverloo [1] https://bugs.webkit.org/show_bug.cgi?id=42093 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Error checking out WebKit
On Tue, Dec 14, 2010 at 07:19, Kenneth Russell k...@google.com wrote: Hi all, Trying to check out a fresh WebKit tree on Windows using svn 1.6.6 (also tried 1.6.1), I'm consistently getting the following error: svn: PROPFIND of '/repository/webkit/!svn/bc/19963/trunk/LayoutTests/fast/xpath/4XPath/Core/test.js': 207 Multi-Status (http://svn.webkit.org) Looking at the subversion log of that file on another machine, it looks like there was an attempt to fix this, but it doesn't seem to have worked. All of my other WebKit checkouts on both Mac OS X and Windows are working fine. I just zipped up the Core directory from another machine, unzipped it into my new tree (thereby picking up the .svn directory) and it looks like the checkout is continuing past this point. It looks like there may be a problem for all users checking out WebKit afresh right now. Does anyone have any idea what the problem is? Thanks, -Ken ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev [On-list this time] I ran into the same problem when checking out WebKit (on Windows) a coulpe of weeks ago. Following some older posts on this mailinglist, it turned out you have to remove the 4XPath folder and check it out separately. While this, obviously, is a work-around, it allowed me to checkout the entire repository. Later updates (via the update-webkit script) weren't bothered by this. Regards, Peter ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Use of -webkit- prefix on CSS Values and Properties
On Sun, Mar 27, 2011 at 18:07, Eric Seidel e...@webkit.org wrote: Do we have any guidelines as to when we use -webkit- for new properties vs not? For example, when implementing CSS3 properties (like we are this week for the BiDi sprint): https://bugs.webkit.org/show_bug.cgi?id=57181 https://bugs.webkit.org/show_bug.cgi?id=50951 It's unclear to me whether -webkit- is required (or even desired) in these cases. It would be useful to have more general guidance (in a public place) as well. -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev There was some discussion about this a while ago on www-style[1], based on which Tantek Çelik sketched the following proposal: http://wiki.csswg.org/spec/vendor-prefixes The proposal concludes that the right time would be after the spec reaches Candidate Recommendation-status, albeit with certain exceptions. While this doesn't necessarily apply to WebKit, it should be kept in mind. Regards, Peter [1] http://lists.w3.org/Archives/Public/www-style/2011Mar/0007.html ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Is Harmony a new WebKit project?
An e-mail was sent to webkit-dev about this four hours ago, titled: [webkit-dev] JavaScriptCore and ES6 Peter On Thu, Dec 15, 2011 at 16:24, Darin Adler da...@apple.com wrote: I see some work in JavaScriptCore on something named Harmony. Is adding this a WebKit project? If so, then I’d like to see the customary webkit-dev message announcing the new project so we can discuss it. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How to Port Webkit to Andriod?
On Fri, Dec 16, 2011 at 08:11, michaelwang michaelw...@linpus.com wrote: Hi,All: Is there anyone have done the job of porting Webkit to Andriod platform? The Android port was partially upstreamed to WebKit, until it was removed earlier this year following an announcement by the Android team: https://lists.webkit.org/pipermail/webkit-dev/2011-August/017738.html https://bugs.webkit.org/show_bug.cgi?id=66688 Work is being done allowing the WebKit Chromium port to be build on Android, for which a meta-bug and build instructions are available. It is currently unable to link and/or run. https://bugs.webkit.org/show_bug.cgi?id=66687 http://trac.webkit.org/wiki/Chromium#BuildingonAndroid Best, Peter Thanks. Michael ___ 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] About code reviews outside bugzilla
The bugzilla bug is here, it's just not referenced in the message (which it should be): https://bugs.webkit.org/show_bug.cgi?id=75956 Peter On Tue, Jan 10, 2012 at 14:44, Philippe Normand ph...@igalia.com wrote: Hi, I thought any substantial code contribution was to be reviewed in a proper bugzilla entry? This commit broke the WebKit2 build earlier today: http://trac.webkit.org/changeset/104557 No mention of a bugzilla entry... Hopefully Kenneth was quick coming up with a build fix, but please let's use Bugzilla... In the case of this patch, the build breakage would have been detected upfront by the EWS. Philippe ___ 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] git.webkit.org is offline
For those with a git-svn checkout, git svn fetch and git svn rebase are working fine for me. Peter On Wed, Feb 15, 2012 at 14:39, Andy Estes aes...@apple.com wrote: I'm seeing this when I try to update my tree: [estes@bestes OpenSource (master)]$ git fetch git.webkit.org[0: 17.254.20.231]: errno=Connection refused fatal: unable to connect a socket (Connection refused) -Andy On Feb 15, 2012, at 11:29 AM, William Siegrist wrote: All services are back. -Bill On Feb 15, 2012, at 8:55 AM, William Siegrist wrote: That server (which includes git, build, nightly, and lists) is having trouble keeping up with load, probably due to a disk array problem. I will be rebooting it one more time in an hour or two to try to clear up the problem. -Bill On Feb 15, 2012, at 6:38 AM, Osztrogonac Csaba wrote: Hi, It seems git.webkit.org is offline. Could you check what happened? br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] git.webkit.org problem
Hi Bill, Would it be possible to get some more information on your/Lucas' plans on improving stability of the infrastructure? This was the third significant interruption within a week, and especially for us non-PST folks it's becoming quite inconvenient. Thanks, Peter On Wed, Feb 29, 2012 at 15:00, William Siegrist wsiegr...@apple.com wrote: This should be fixed now. -Bill On Feb 29, 2012, at 3:19 AM, David Barr wrote: Is it any trick to update my git-svn repo from svn? I set up my git svn repo about $http://trac.webkit.org/wiki/UsingGitWithWebKit : - git clone git://git.webkit.org/WebKit.git WebKit - git svn init --prefix=origin/ -T trunk http://svn.webkit.org/repository/webkit - git config --replace svn-remote.svn.fetch trunk:refs/remotes/origin/master Usually, the only missing step here is 'git svn fetch'. However, when I run that now I get: RA layer request failed: OPTIONS of 'http://svn.webkit.org/repository/webkit': could not connect to server (http://svn.webkit.org) at /Users/davidbarr/libexec/git-core/git-svn line 2139 -- David Barr. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] git.webkit.org problem
Hi Lucas, Thank you very much for your answer! One change that was applied to Chromium's build bot console[1] recently was to cache the overview page for a minute. This may be relevant to the Apache caching layer you mentioned. If requests are really handled serially then updating to version 0.8.5 would hopefully yield performance improvements as well. Peter [1] http://chromium-build-master.appspot.com/p/chromium/console On Wed, Feb 29, 2012 at 19:32, Lucas Forschler lforsch...@apple.com wrote: Hi Peter, I am looking into improving performance of build.webkit.org. After doing some initial research I feel that buildbot isn't the most efficient in terms of processing a large number of requests. I believe requests are processed serially, and not in parallel. The buildbot documentation mentions a limit to the number of slaves that can be supported, but doesn't give any specific numbers. As webkit has grown, and the number of builds and slaves we are supporting has increased, it seems the server is showing signs of reaching this capacity. We may have reached a limit on the number of slaves we can handle with our current configuration. Some of the things I have been researching to increase build.webkit.orgperformance include the following: -Upgrades to hardware. It's possible faster hardware could alleviate some problems. It is unclear if this is really the limiting factor, or how much additional capacity this would provide. -Updating the way files are transferred (https://bugs.webkit.org/show_bug.cgi?id=73484) -Upgrade the version of buildbot. (0.8.3 - 0.8.5). Version 0.8.4 and higher supposedly has a threading improvement, but it's unclear how much it would benefit us since it looks to be mostly database related. -Upgrading the version of twisted running on the sever. We are currently at version 8.2, and version 12 is now available. -Investigating some kind of apache caching layer on top of buildbot -Adding a second master to the buildbot system. buildbot supports multi-master mode. We could potentially split out build and test onto two separate masters. build.webkit.org and test.webkit.org ? I would be interested in hearing any other thoughts on increasing build.webkit.org performance. Lucas On Feb 29, 2012, at 7:08 AM, Peter Beverloo wrote: Hi Bill, Would it be possible to get some more information on your/Lucas' plans on improving stability of the infrastructure? This was the third significant interruption within a week, and especially for us non-PST folks it's becoming quite inconvenient. Thanks, Peter On Wed, Feb 29, 2012 at 15:00, William Siegrist wsiegr...@apple.comwrote: This should be fixed now. -Bill On Feb 29, 2012, at 3:19 AM, David Barr wrote: Is it any trick to update my git-svn repo from svn? I set up my git svn repo about $http://trac.webkit.org/wiki/UsingGitWithWebKit : - git clone git://git.webkit.org/WebKit.git WebKit - git svn init --prefix=origin/ -T trunk http://svn.webkit.org/repository/webkit - git config --replace svn-remote.svn.fetch trunk:refs/remotes/origin/master Usually, the only missing step here is 'git svn fetch'. However, when I run that now I get: RA layer request failed: OPTIONS of 'http://svn.webkit.org/repository/webkit': could not connect to server (http://svn.webkit.org) at /Users/davidbarr/libexec/git-core/git-svn line 2139 -- David Barr. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Websocket enabling on android 4.0.3
Hello Priyadarshini, An Web Sockets implementation will also require a client-side implementation, which is not provided in the Android port. You'll want to file a feature request against http://code.google.com/p/android/, or switch to using the Chrome on Android beta which does support the feature: http://www.google.com/intl/en/chrome/android/ In either case, since the Android port is not upstreamed to WebKit, I'm afraid your question is out of scope for this list. Peter On Mon, May 7, 2012 at 6:48 PM, priya s priyas...@gmail.com wrote: Hello I am trying to enable web socket feature on android 4.0.3 native browser. i.e WEB-SOCKET flag in android 4.0.3 (ICS) webkit code. (#if ENABLE (WEB_SOCKET)). I have refered http://trac.webkit.org/wiki/AddingFeatures link to enable WEB-SOCKET flag. Still there is no difference in the build. Please let me know the detailed procedure to enable WEB-SOCKET flag in android webkit code base. -- Regards, Priyadarshini ___ 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] Using the WebExposed keyword for web-facing changes
Hi webkit-dev, *If you work on web-facing features, or run into another bug which does, please consider adding the WebExposed keyword to it.* Many of you will be familiar with my WebKit updates, which are now also being published on the WebKit blog. Writing these involves reading every commit that lands in WebKit's repository. Last year, May counted 2,126 revisions. This year there were 3,068. As a result of the steep increase in volume, it's becoming increasingly hard for all parties to keep up -- Web(Kit) developers, ports and all other interested parties. Not every one of them has time to read through all changes. In an effort to increase visibility of Web Platform facing changes, I'd like to introduce the WebExposed keyword. It is intended to be applied to any bug which introduces, modifies (including behavioral changes) or removes features important to Web developers, such as DOM properties and methods, JavaScript features and CSS properties and values. https://bugs.webkit.org/buglist.cgi?keywords=WebExposed Increased visibility of these changes has a number of advantages. Firstly, Web Developers will have more insight in what's happening in WebKit. The changes will be visible on the bug list itself, but also through the RSS feed Bugzilla will curate for it. Furthermore, it may be used as an overview for ports to keep track of the web-facing changes which happen during their release cycles, and it will also come in useful for evangelizing features, writing documentation and managing outreach. With work being done by many vendors in many areas of WebCore, I'm hoping the keyword can become a valuable aid in this respect. If you work on web-facing features, or run into another bug which does, please consider adding the WebExposed keyword to it. This of course isn't mandatory, but it will help others who are interested in keeping track. Thanks, Peter ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Using the WebExposed keyword for web-facing changes
On Mon, Jun 11, 2012 at 2:08 AM, TAMURA, Kent tk...@chromium.org wrote: Do you want WebExposed for a simple bug fix of an existing feature? Do you want it for bugs with no patches? If the change might impact Web Developers - yes. Of course, use your own judgement here; it won't have much benefit for minor fixes on a feature in very early stages of development which is still disabled on all major ports. However, when in doubt, it's better to be on the safe side and add the label. Using it for bugs without patches is fine, of course. Thanks, Peter On Sat, Jun 9, 2012 at 5:24 AM, Peter Beverloo pe...@chromium.org wrote: Hi webkit-dev, *If you work on web-facing features, or run into another bug which does, please consider adding the WebExposed keyword to it.* Many of you will be familiar with my WebKit updates, which are now also being published on the WebKit blog. Writing these involves reading every commit that lands in WebKit's repository. Last year, May counted 2,126 revisions. This year there were 3,068. As a result of the steep increase in volume, it's becoming increasingly hard for all parties to keep up -- Web(Kit) developers, ports and all other interested parties. Not every one of them has time to read through all changes. In an effort to increase visibility of Web Platform facing changes, I'd like to introduce the WebExposed keyword. It is intended to be applied to any bug which introduces, modifies (including behavioral changes) or removes features important to Web developers, such as DOM properties and methods, JavaScript features and CSS properties and values. https://bugs.webkit.org/buglist.cgi?keywords=WebExposed Increased visibility of these changes has a number of advantages. Firstly, Web Developers will have more insight in what's happening in WebKit. The changes will be visible on the bug list itself, but also through the RSS feed Bugzilla will curate for it. Furthermore, it may be used as an overview for ports to keep track of the web-facing changes which happen during their release cycles, and it will also come in useful for evangelizing features, writing documentation and managing outreach. With work being done by many vendors in many areas of WebCore, I'm hoping the keyword can become a valuable aid in this respect. If you work on web-facing features, or run into another bug which does, please consider adding the WebExposed keyword to it. This of course isn't mandatory, but it will help others who are interested in keeping track. Thanks, Peter ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- TAMURA Kent Software Engineer, Google ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New Feature Flag Proposal: TIME_INPUT_FIELDS
On Tue, Jun 26, 2012 at 9:20 PM, Yosi Inoue yo...@chromium.org wrote: Hi WebKit! I would like to notify adding new feature flag ENABLE_TIME_INPUT_FIELDS. This flag will enable multiple fields input UI for input type time. Looking is as same as input type number (including spin button), but each time component, hour, minute, second, millisecond, period(AM/PM), is fixed and handles keyboard input as overwriting rather than inserting, like Mac OSX's DateTime control. This feature will be enable for desktop version of Chrome (== excluding Android). Android already enables time (and date) inputs, and defers to the platform's input mechanisms. Will the appearances of the controls be consolidated? Peter This flag also introduce following class and functions: * DateTimeFormat class * localizedDecimalSeparator() * localizedTimeFormat() * localizedShortTimeFormat() * DateTimeFIeldElement (for shadow DOM) * DateTimeEditElement (for shadow DOM) Thanks! ___ 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] Indexeddb support status in latest nightly build
Please direct your questions to no more than one mailing list at a time. webkit-help is most appropriate for this kind of question, as webkit-dev is intended for WebKit developers and implementers. As far as I'm aware, IndexedDB is not available in the latest nightly builds. Peter On Sat, Jul 28, 2012 at 1:53 PM, Navanshu Mahor mahor1...@gmail.com wrote: Has the indexed db been implemented in latest nigthly build ?? Thanks Regards, Navanshu ___ 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] Can we remove webkit prefix from Battery Status API and from Vibration API?
On Tue, Jul 31, 2012 at 3:02 AM, Kihong Kwon kihong.k...@samsung.comwrote: Hi, webkit-dev ** ** As you can see with these links, http://www.w3.org/TR/battery-status/ http://www.w3.org/TR/vibration/ the status of Battery Status API and Vibration API have been changed to the CR quite ago and specs are almost stable now. Therefore, I think we can remove webkit prefix from webkitBattery and from webkitvibrate. If someone has objection or other opinion please let me know. Has a test suite been published we can test against? Are there any other implementations of the APIs? Besides the time-based requirement of dropping vendor prefixes when a specification goes to Candidate Recommendation status, unprefixing also implies operability with both the specification and other implementations. It'll be good to confirm that. Peter BR, Kihong. ___ 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] Kerning not working for SVG font when included in HTML file using @font-face
Please use the webkit-h...@lists.webkit.org mailing list for questions such as this one, as webkit-dev is intended as a forum for WebKit developers. In general, if exactly the same code behaves differently in WebKit compared to other browsers, or WebKit's implementation is different from what the specification says, you're always welcome to file a bug on http://bugs.webkit.org/. Thanks, Peter On Wed, Aug 1, 2012 at 5:23 PM, tony tonyii...@gmail.com wrote: Hi, I created a SVG font file and wanted to try kerning between two glyphs (V and G in the attached file). The kerning works when open the SVG in browser but does not work if i include it in HTML styles using @font-face. Please let me know if i am doing something wrong or is it a bug in webkit. PS: The same SVG font file when converted to ttf and the ttf refered to using @font-face in HTML works fine in Firefox14. Thanks Tony ___ 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] Procedure for adding new blogs to the WebKit Planet
On Thu, Aug 2, 2012 at 10:00 AM, Patrick Gansterer par...@paroga.comwrote: On Thu, 02 Aug 2012 10:53:30 +0200, Martin Robinson wrote: Hi all, What's the procedure for adding a blog to the WebKit Planet? I often post material interesting to some of the WebKit community, but not suitable for Surfin' Safari since it is often specific to WebKitGTK+ or to just a subset of ports. Change http://trac.webkit.org/**browser/trunk/Websites/planet.** webkit.org/config.inihttp://trac.webkit.org/browser/trunk/Websites/planet.webkit.org/config.inilet it review. ;-) Yup, feel free to do so :-). More updates about WebKit-related work always is a good thing! I've posted a patch for removing blogs which no longer are being updated here, of course with the involved owners cc'ed: https://bugs.webkit.org/show_bug.cgi?id=92973 Peter ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] bugs.webkit.org and trac.webkit org down?
On Thu, Aug 9, 2012 at 11:09 AM, Mark Rowe mr...@apple.com wrote: On 2012-08-09, at 02:41, Osztrogonac Csaba o...@inf.u-szeged.hu wrote: Hi, bugs.webkit.org and trac.webkit.org is unavailable again. :( Could you check it, please? This is caused by a problem on a host that I don't have sufficient privileges on to be able to address the issue myself. I've pinged people that should be able to resolve the issue, but given that it's currently 3am in California it may be a few hours before they're awake and fixing it. Thank you. Is there any way an on-call or monitoring system could be set up? While it fortunately occurs much less frequently nowadays than it did earlier in the year, it --please excuse my directness-- is unacceptable for a project the size of WebKit to have critical infrastructure unavailable like this for several hours. Even though it's 3am in California, there are many contributors in Asia and Europe who are severely impacted by this. Peter - Mark br, Ossy Osztrogonac Csaba írta: It seems bugs.webkit.org and trac.webkit.org is unavailable now. (at least from Hungary) Have you got any idea what happened? ___ 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
Re: [webkit-dev] bugs.webkit.org and trac.webkit org down?
On Thu, Aug 9, 2012 at 11:41 AM, Mark Rowe mr...@apple.com wrote: On 2012-08-09, at 03:14, Peter Beverloo pe...@chromium.org wrote: On Thu, Aug 9, 2012 at 11:09 AM, Mark Rowe mr...@apple.com wrote: On 2012-08-09, at 02:41, Osztrogonac Csaba o...@inf.u-szeged.hu wrote: Hi, bugs.webkit.org and trac.webkit.org is unavailable again. :( Could you check it, please? This is caused by a problem on a host that I don't have sufficient privileges on to be able to address the issue myself. I've pinged people that should be able to resolve the issue, but given that it's currently 3am in California it may be a few hours before they're awake and fixing it. Thank you. Is there any way an on-call or monitoring system could be set up? While it fortunately occurs much less frequently nowadays than it did earlier in the year, it --please excuse my directness-- is unacceptable for a project the size of WebKit to have critical infrastructure unavailable like this for several hours. Even though it's 3am in California, there are many contributors in Asia and Europe who are severely impacted by this. We have people online virtually 24x7 that are capable of investigating and addressing issues with the webkit.org infrastructure. I'm one such person. This particular case is an unfortunate combination of events: a configuration error on a subset of the new hardware that webkit.org was recently migrated to has unintentionally limited the number of people that can access the host that is currently experiencing problems, and the person that such issues are escalated to is currently on vacation. It's an unfortunate combination, but also one that is unlikely to repeat. One thing we should look in to is improving the process for reporting issues with webkit.org infrastructure. webkit-dev isn't an ideal way to report issues that our monitoring system hasn't noticed as there's no separation between the regular discussion and more urgent issues, so the emails can be overlooked. I see. Thank you for the insight, and I hope the access issues get sorted out. I presume this is something Bill or Lucas will be able to pick up? Hopefully the remaining downtime won't be more than three or four hours, then. Peter - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] bugs.webkit.org and trac.webkit org down?
On Thu, Aug 9, 2012 at 12:49 PM, Mark Rowe mr...@apple.com wrote: On 2012-08-09, at 04:22, Peter Beverloo pe...@chromium.org wrote: On Thu, Aug 9, 2012 at 11:41 AM, Mark Rowe mr...@apple.com wrote: On 2012-08-09, at 03:14, Peter Beverloo pe...@chromium.org wrote: On Thu, Aug 9, 2012 at 11:09 AM, Mark Rowe mr...@apple.com wrote: On 2012-08-09, at 02:41, Osztrogonac Csaba o...@inf.u-szeged.hu wrote: Hi, bugs.webkit.org and trac.webkit.org is unavailable again. :( Could you check it, please? This is caused by a problem on a host that I don't have sufficient privileges on to be able to address the issue myself. I've pinged people that should be able to resolve the issue, but given that it's currently 3am in California it may be a few hours before they're awake and fixing it. Thank you. Is there any way an on-call or monitoring system could be set up? While it fortunately occurs much less frequently nowadays than it did earlier in the year, it --please excuse my directness-- is unacceptable for a project the size of WebKit to have critical infrastructure unavailable like this for several hours. Even though it's 3am in California, there are many contributors in Asia and Europe who are severely impacted by this. We have people online virtually 24x7 that are capable of investigating and addressing issues with the webkit.org infrastructure. I'm one such person. This particular case is an unfortunate combination of events: a configuration error on a subset of the new hardware that webkit.org was recently migrated to has unintentionally limited the number of people that can access the host that is currently experiencing problems, and the person that such issues are escalated to is currently on vacation. It's an unfortunate combination, but also one that is unlikely to repeat. One thing we should look in to is improving the process for reporting issues with webkit.org infrastructure. webkit-dev isn't an ideal way to report issues that our monitoring system hasn't noticed as there's no separation between the regular discussion and more urgent issues, so the emails can be overlooked. I see. Thank you for the insight, and I hope the access issues get sorted out. I presume this is something Bill or Lucas will be able to pick up? Hopefully the remaining downtime won't be more than three or four hours, then. Bill is the one that's on vacation, and Lucas is in the same boat that I am as far as access to the host in question. I managed to track down someone else with sufficient access though, and they've fixed the issue that was impacting bugs.webkit.org and trac.webkit.org. Awesome, cheers! Peter - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Chromium for Android builders have been added to the EWS
Hi WebKit, Starting yesterday, a queue is now available for the Early Warning System (EWS) which will be building --but not testing-- all patches uploaded to Bugzilla for the Chromium for Android configuration. Compared to Chromium Linux, the main differences are that Android will cross-compile the entire project to the ARMv7 architecture (thumb, with NEON disabled); the list of enabled features is slightly different[1], and some source files have Android-specific implementations. Finally, after building the .so libraries is complete, it will create .apk (Android Application Package) files for each major target. The queue[2] currently still has more than 300 patches pending, which seems to include every patch that's still pending review or commit. If you get build failure notices on patches that haven't been touched for months, please feel free to ignore them. We plan to add a tester to the waterfall in the next few weeks, which will also be running all unit tests, API tests and Layout Tests on actual devices. Thanks, Peter [1] http://trac.webkit.org/browser/trunk/Source/WebKit/chromium/features.gypi#L148 [2] http://webkit-commit-queue.appspot.com/queue-status/cr-android-ews ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Chromium for Android builders have been added to the EWS
On Sun, Aug 12, 2012 at 4:20 PM, Antonio Gomes toniki...@gmail.com wrote: Nice work. I assume your upstreaming is done. We are getting very close! API compatibility is the next milestone (which only is one or two APIs away at this point), after which the remaining code is mostly long-term work (Text Autosizing and some compositor features). On Fri, Aug 10, 2012 at 6:47 AM, Kenneth Rohde Christiansen kenneth.christian...@gmail.com wrote: Nice to hear and congratulation with getting so far! I am very happy that you are aiming at having a working mobile port in trunk; similar goals that we have for the Qt port. Same for the BlackBerry port. Cool! The more, the merrier, of course. Peter -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal to enable compile flags only for EWS run
It depends on the kind of feature you're working on, indeed. While I don't know what Bruno's use-case is, In the case of text decoration, I guess it could involve testing the complex test code paths which can be different for port/platform combinations. Peter On Thu, Aug 16, 2012 at 6:00 PM, Adam Barth aba...@webkit.org wrote: Why not just build and run the tests locally? This sounds like a CSS feature that should more or less work the same for every port. Adam On Thu, Aug 16, 2012 at 9:53 AM, Peter Beverloo pe...@chromium.org wrote: Depending on how much longer the feature will be in development, it may not be worth setting up a new bot. Bruno seems to be mostly interested in getting EWS results, whereas results on the waterfall would only show up after committing the actual change. Something you could consider is to have a patch specifically crafted for getting EWS results. To take the Chromium Linux EWS bot as an example, you can enable the feature in Chromium's features.gypi and remove the SKIP entry from the TestExpectations file (these changes need to be in the patch itself), asking the bot to compile everything and run layout tests for the feature. As this patch wouldn't be intended to be committed, don't request review or commit, and manually click on the Request EWS button on the Bugzilla page. If you're using webkit-patch, this would work: webkit-patch upload --no-review -m Patch for EWS Similar changes can be made to enable it for other ports as well, i.e. for the Mac port which also runs layout tests. A downside of this is that you have to maintain a certain boilerplate of code for enabling your feature, and that you have to remember to remove this boilerplate when uploading the patch for review and/or commit. I guess you could set up a git workflow to make this a lot easier, though. Peter On Thu, Aug 16, 2012 at 5:38 PM, Adam Barth aba...@webkit.org wrote: Currently the EWS bots use the same configuration as the bots on build.webkit.org. We do that so they give accurate information about what effect a given patch is going to have on the state of the tree when the patch lands. If we build using different flags on the EWS than on build.webkit.org, they lose that predictive power. What we've done to address this issue in the past is to set up a new bot on build.webkit.org that builds and tests with flag turned on. For example, during the development of flexbox, we had a flexbox bot that the folks who worked on flexible cared about and everyone else ignored. I believe we did the same thing for grid layout. I'd recommend setting up a separate bot on build.webkit.org. Adam On Thu, Aug 16, 2012 at 6:13 AM, Bruno Abinader brunoabina...@gmail.com wrote: Hi WebKit :) As previously discussed, we decided that compile flag only was the best option for CSS3 Text Decoration feature set (landed in http://trac.webkit.org/changeset/125716 ). I believe this was a general decision and got promptly implemented as such (however I still maintain a runtime flag patch at https://bugs.webkit.org/show_bug.cgi?id=93966 in case it is ever needed). What I want to discuss is an issue that raises with the decision to only have compile flag: As it comes disabled by default, further development on this feature will not be able to be checked by EWS or any other build bot. This affects layout tests regression checking and compile-time error checking, so I wonder how can we manage to fix this? I have some proposals below: 1) Propose a special EWS-only build variable to contain compile flags not enabled by default. I might not know how difficult it would be to implement this, but sounds like a clean approach to me. 2) Change compile flag value to become enabled by default. I believe this is not possible because, as discussed earlier, it would prematurely expose the feature to the web. 3) Add runtime flag, so compile flag would be enabled by default, but runtime flag would be disabled. That was I actually proposed in http://lists.webkit.org/pipermail/webkit-dev/2012-August/021878.html (CSS Regions implements like this, with both compile and runtime flags). Assuming that 2) and 3) are not possible due to previous discussion, this makes me wonder if 1) is feasible. I believe other feature flags might had the same situation before, so how you guys managed to check for errors? I appreciate your input and feedback! Best regards, -- Bruno de Oliveira Abinader ___ 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] Proposal to enable compile flags only for EWS run
Depending on how much longer the feature will be in development, it may not be worth setting up a new bot. Bruno seems to be mostly interested in getting EWS results, whereas results on the waterfall would only show up after committing the actual change. Something you could consider is to have a patch specifically crafted for getting EWS results. To take the Chromium Linux EWS bot as an example, you can enable the feature in Chromium's features.gypi and remove the SKIP entry from the TestExpectations file (these changes need to be in the patch itself), asking the bot to compile everything and run layout tests for the feature. As this patch wouldn't be intended to be committed, don't request review or commit, and manually click on the Request EWS button on the Bugzilla page. If you're using webkit-patch, this would work: webkit-patch upload --no-review -m Patch for EWS Similar changes can be made to enable it for other ports as well, i.e. for the Mac port which also runs layout tests. A downside of this is that you have to maintain a certain boilerplate of code for enabling your feature, and that you have to remember to remove this boilerplate when uploading the patch for review and/or commit. I guess you could set up a git workflow to make this a lot easier, though. Peter On Thu, Aug 16, 2012 at 5:38 PM, Adam Barth aba...@webkit.org wrote: Currently the EWS bots use the same configuration as the bots on build.webkit.org. We do that so they give accurate information about what effect a given patch is going to have on the state of the tree when the patch lands. If we build using different flags on the EWS than on build.webkit.org, they lose that predictive power. What we've done to address this issue in the past is to set up a new bot on build.webkit.org that builds and tests with flag turned on. For example, during the development of flexbox, we had a flexbox bot that the folks who worked on flexible cared about and everyone else ignored. I believe we did the same thing for grid layout. I'd recommend setting up a separate bot on build.webkit.org. Adam On Thu, Aug 16, 2012 at 6:13 AM, Bruno Abinader brunoabina...@gmail.com wrote: Hi WebKit :) As previously discussed, we decided that compile flag only was the best option for CSS3 Text Decoration feature set (landed in http://trac.webkit.org/changeset/125716 ). I believe this was a general decision and got promptly implemented as such (however I still maintain a runtime flag patch at https://bugs.webkit.org/show_bug.cgi?id=93966 in case it is ever needed). What I want to discuss is an issue that raises with the decision to only have compile flag: As it comes disabled by default, further development on this feature will not be able to be checked by EWS or any other build bot. This affects layout tests regression checking and compile-time error checking, so I wonder how can we manage to fix this? I have some proposals below: 1) Propose a special EWS-only build variable to contain compile flags not enabled by default. I might not know how difficult it would be to implement this, but sounds like a clean approach to me. 2) Change compile flag value to become enabled by default. I believe this is not possible because, as discussed earlier, it would prematurely expose the feature to the web. 3) Add runtime flag, so compile flag would be enabled by default, but runtime flag would be disabled. That was I actually proposed in http://lists.webkit.org/pipermail/webkit-dev/2012-August/021878.html (CSS Regions implements like this, with both compile and runtime flags). Assuming that 2) and 3) are not possible due to previous discussion, this makes me wonder if 1) is feasible. I believe other feature flags might had the same situation before, so how you guys managed to check for errors? I appreciate your input and feedback! Best regards, -- Bruno de Oliveira Abinader ___ 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
Re: [webkit-dev] Proposal to enable compile flags only for EWS run
On Thu, Aug 16, 2012 at 7:25 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Aug 16, 2012 at 11:01 AM, Bruno Abinader brunoabina...@gmail.comwrote: On Thu, Aug 16, 2012 at 1:28 PM, Adam Barth aba...@webkit.org wrote: In that case, he might want to start with one port, get that working well, and then expand to the other ports. Adam That's exactly what I am doing :) As I'm mostly familiar with Qt, it is the chosen platform were I am basing layout test results. I'm building and testing locally, both with and without the feature flag enabled, to make sure I'm not breaking any previous behavior. All new CSS3 text decorations are getting proper layout tests, and I am also taking care of editing feature, which I found proper spec already ( https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html ) and studying it. So far I just found basic text decoration support, so this is pretty well assured by current implementation. On Thu, Aug 16, 2012 at 10:03 AM, Peter Beverloo pe...@chromium.org wrote: It depends on the kind of feature you're working on, indeed. While I don't know what Bruno's use-case is, In the case of text decoration, I guess it could involve testing the complex test code paths which can be different for port/platform combinations. Indeed. So far there were no big changes between platforms (except pixel tests font size/type differences, for instance). But it's always good to be backed by EWS results to be sure everything's fine. I enjoyed your solution (to provide a separate patch to make EWS run the tests) which won't get landed, and that's what I'm going to do until we find a better solution. Thanks for the input! FYI, non-Chromium EWS don't run tests. The Mac EWS used to run tests, until about a week ago. They're disabled until more hardware is available (see r125058), but hopefully it also means tests will eventually be ran again :-). Peter - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New feature: CSS3 GCPM
Anything specific or the whole specification? The mixture of features defined in there covers a rather broad spectrum, and sometimes overlaps with features defined elsewhere (i.e. float modifiers v.s. positioned floats, CMYK colors which probably shouldn't be there). Is there a meta bug we can track? Thanks, Peter On Mon, Aug 20, 2012 at 5:15 PM, David Hyatt hy...@apple.com wrote: You're going to see some patches in the coming weeks (first one coming soon) to begin work on implementing: http://www.w3.org/TR/css3-gcpm/ In some cases, there are going to be syntactic deviations from the spec as we experiment (based off discussions that are ongoing in the CSS WG), but in general we'll be implementing the features in the working draft. dave (hy...@apple.com) ___ 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] New feature: CSS3 GCPM
Addendum: The current Editor's Draft is significant different from the published WD, and includes something similar to CSS Exclusions. Since Adobe is implementing these in WebKit, it may be good to know what your ideas on these are as well :-). http://dev.w3.org/csswg/css3-gcpm/ Thanks, Peter On Mon, Aug 20, 2012 at 5:20 PM, Peter Beverloo pe...@chromium.org wrote: Anything specific or the whole specification? The mixture of features defined in there covers a rather broad spectrum, and sometimes overlaps with features defined elsewhere (i.e. float modifiers v.s. positioned floats, CMYK colors which probably shouldn't be there). Is there a meta bug we can track? Thanks, Peter On Mon, Aug 20, 2012 at 5:15 PM, David Hyatt hy...@apple.com wrote: You're going to see some patches in the coming weeks (first one coming soon) to begin work on implementing: http://www.w3.org/TR/css3-gcpm/ In some cases, there are going to be syntactic deviations from the spec as we experiment (based off discussions that are ongoing in the CSS WG), but in general we'll be implementing the features in the working draft. dave (hy...@apple.com) ___ 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] EditBugs permission request
On Tue, Aug 21, 2012 at 11:42 PM, Adam Barth aba...@webkit.org wrote: On Tue, Aug 21, 2012 at 2:41 PM, Glenn Adams gl...@skynav.com wrote: Could I be enabled for EditBugs permission? I'm starting to submit patches and actively work bugs, e.g., Done. In the future, folks should feel free to ask folks (including me) on #webkit rather than emailing webkit-dev, which has many subscribers. There have been a few people asking for the permission during non-PST times as well, and it's very unclear which people are able to set EditBugs. Can the ability to set this be granted to all Reviewers? While requests aren't *extremely* common, increasing the set of people who are able to grant EditBugs -especially across timezones- would be both convenient and much clearer. Peter ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] https://trac.webkit.org/auth/login/ down?
The page itself can be loaded just fine, but blocking requests to static2.macosforge.org are timing out. If you wait for a minute or so the unstyled content will show up, including the login form, which works just fine. Peter On Fri, Oct 19, 2012 at 6:38 PM, Pablo Flouret pab...@motorola.com wrote: Hey, Trac itself seems up, but not the /auth/ parts. Anyone else seeing this? Cheers, -- pablo flouret motorola | webkit / browser team ___ 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] does anyone still use 'webkit-patch rebaseline-server'?
On Wed, Oct 31, 2012 at 10:47 PM, Dirk Pranke dpra...@chromium.org wrote: It is/was intended to be useful for quickly reviewing and rebaselining a bunch of failures in a local (on-disk) checkout. It's been largely unmaintained and ignored for quite some time in favor of garden-o-matic. I have recently started to land some patches that will make garden-o-matic work locally as well as with the bots, and it will ultimately replace rebaseline-server; I'm attempting to consolidate all of our different change-reviewing UIs so that they are more consistent and share more code. The local garden-o-matic should roughly work now, but the UI isn't well-tuned for this use case and there's some things left do to. If you have any features you would like to add to the garden-o-matic UI (or want to make sure are transferred over from rebaseline-server), now would be a good time to mention them. And, if no one speaks up to say that rebaseline-server is still being used, I will assume I can delete it when I'm ready to do so. Thanks! I'm still using this for landing Android baselines, and would appreciate if it could stick around for another two weeks. I'll definitely start looking in to using garden-o-matic for this purpose as well, however. It's great that the tools we have are converging into a few more powerful, common ones! Thanks, Peter -- 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] List of IRC nicknames pictures?
IRC nicknames are available in committers.py, as the third argument of the Contributor, Committer and Reviewer entries: http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common/config/committers.py I'm not aware of any picture database. I guess we could include them on the WebKit Team wiki page, but I'm not convinced the benefit would be worth the effort of adding that much images. If you use Gmail as your e-mail client, it'll somehow figure out these images anyway. Peter On Sun, Nov 4, 2012 at 11:10 AM, Ryosuke Niwa rn...@webkit.org wrote: Hi, Do you think we can have a list of IRC nicknames profile pictures of WebKit contributors somewhere? Since most of us see each other in person only once a year, I can't really keep everyone's face name straight without a database like that. Best, - R. Niwa ___ 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] Chromium for Android upstreaming has been completed!
Hi WebKit! Following Adam’s progress update on the Chromium-Android port in July[1], we’re happy to tell you that our upstreaming has been completed and that the Chromium-Android port is now fully supported. We’ve closed the master bug: https://bugs.webkit.org/show_bug.cgi?id=66687 To give you a quick summary: * Chromium for Android builds upon the existing Chromium architecture, code and port. * Build bots are available on the WebKit waterfall, with layout tests being run on actual devices. * There are EWS bots building all patches as they’re being uploaded to Bugzilla. Of course there are more loose ends to address, but we expect to finish these not too long from now. Most notably, a Performance bot will be added to the WebKit waterfall and all tools, including garden-o-matic, will be brought up to speed for Android. Once again, huge thanks to the WebKit community for being supportive and helping us out not just on upstreaming, but also in development of features such as Text Autosizing[2]. Cheers, Peter and Adam [1] http://lists.webkit.org/pipermail/webkit-dev/2012-July/021516.html [2] https://bugs.webkit.org/show_bug.cgi?id=84186 ___ 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
Re: [webkit-dev] Proposal: Make Ninja the default build-system for build-webkit --chromium
Clarifying the error messages seems like a win in either case. From Android's perspective, I'm of course in favor of switching to ninja. One minor nit, but I'll reply with that on the bug. Thanks for doing this! Peter On Mon, Dec 10, 2012 at 9:39 AM, Eric Seidel e...@webkit.org wrote: The buildbots will use ninja by default, but could opt-out (with --no-ninja) if that were desired behavior. I've so far received one other concern: Robert Hogan raised that chromium's depot_tools does not contain a 32-bit build of ninja, and the error message is somewhat confusing in that case. I've filed https://bugs.webkit.org/show_bug.cgi?id=104523 for tracking that issue. On Mon, Dec 10, 2012 at 1:30 AM, Jochen Eisinger joc...@chromium.org wrote: Will the buildbots use ninja or the native build tools? My only concern is that we're catching problems with e.g. MSVS only after we roll the WebKit deps in chromium and one of the MSVS bots starts failing. Otherwise, I'm all for switching to ninja. best -jochen On Sat, Dec 8, 2012 at 9:29 AM, Eric Seidel e...@webkit.org wrote: If you don't work on the Chromium port, feel free to ignore. If you work on the Chromium port of WebKit and do not use Ninja as you build system (GYP_GENERATORS='ninja' or update-webkit --chromium --ninja) I want to hear from you! As far as I can tell, the vast majority of Chromium contributors use Ninja as their build system of choice. Particularly for Chromium-Android contributors this seems to be true. With that knowledge, I have posted a patch to make update-webkit ---chromium/--chromium-android generate Ninja build files instead of platform-native build files (XCode, Visual Studio, Make, etc.) by default. This of course only affects the chromium port. https://bugs.webkit.org/show_bug.cgi?id=104434 Thanks! p.s. If you don't already know: update-webkit --chromium --ninja build-webkit --chromium is all you need to use Ninja today. You don't even need to have installed/built your own copy of ninja (Chromium has done that for you). p.p.s. Ninja is awesome. Awesomely quiet. Awesomely fast. http://martine.github.com/ninja/ ___ 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
