Re: [webkit-dev] New script to import W3C CSS tests
I also got a little inspiration from the import-w3c-performance-wg-tests that already exists. I followed a few of their steps, but had to add a few layers to handle the added complexity of the CSS test suites. Is there any way we can merge the two scripts so there is only one import/exporter than handles both performance and CSS test suites? -Tony ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding archive.org-based page loading time performance tests
Does it matter if the page contents are bad/incomplete? Good point. Seems fine for any given page to be incomplete is a specific way. The only thing that would concern me is if we always miss a certain class of resources. For instance, if we never recorded resources fetched via XHR, it could lead us to miss a class of optimizations or, worse yet, to make a bad tradeoff. -Tony ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] List of prefixed APIs in WebKit
While it'd require some archaeology, would it be useful to compile a list of formerly prefixed APIs which have graduated? -Tony On Sat, Apr 7, 2012 at 2:10 AM, Adam Barth aba...@webkit.org wrote: As you might be aware, there's been some amount of debate in the browser community recently about the use of vendor prefixes in the web platform. I'm sure many of you have opinions on this topic, but rather than triggering a long thread about this topic, I'd like to start by gathering some data about WebKit's current use of vendor prefixes. I've put together a list of all the vendor-prefixed APIs I could find in WebKit, at least for DOM interfaces: https://trac.webkit.org/wiki/PrefixedAPIs I'd like to try to understand the current status of these APIs on the standards track. If you happen to know which specifications contain these various APIs (and the standardization status of these specifications), would you be so kind as to add a link from the wiki to the specification? If there isn't a specification, please feel encouraged to note that on the wiki together with any information you're aware of about future plans for writing a specification. I'll do my best to fill in the gaps in a few days. Many thanks, Adam P.S., If you'd be willing to fill in the list of vendor-prefixed CSS properties, I'd appreciate that as well. ___ 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] Top 100 sites browsing tests proprosal
On Mon, Jan 23, 2012 at 2:14 AM, Aaron Boodman a...@google.com wrote: On Sun, Jan 22, 2012 at 12:00 PM, Peter Kasting pkast...@google.com wrote: On Sun, Jan 22, 2012 at 11:55 AM, Balazs Kelemen kbal...@webkit.org wrote: As the goal is to test real world use case I think it can be even better to simply load the sites from network. I see only two disadvantage of that but neither of them are blocker: 1. The sites changing over time. However, as this would be a smoke test (and not a regtest or a perf test) I don't think it's a big problem 2. Cannot test offline. Well, I don't think taking part in the development of WebKit is possible without being online anyway :) Do you see other disadvantages? Loading over a network connection is slower. Especially if you expect developers to run these tests locally, this could be a serious time sink. Loading real-world sites over a real network connection adds numerous possible flakiness/failure sources. I would never use something like this as part of an automated system. Arguably, it's not kind to site authors to constantly reload their real sites as part of an automated testing program. From experience using offline copies of popular sites for testing in both Firefox and Chrome, I strongly suggest you go the offline route. How would you capture and replay websites offline? This is non-trivial. Very much non-trivial ;) Depending on which route you end up deciding to take, you might also want to consider http://code.google.com/p/web-page-replay/ which scrapes and replays web pages without being tied to a specific browser. It does some fuzzy request matching and injects a bit of JS to ensure deterministic playback w.r.t the issues Aaron mentions here. Without something like that, it is surprisingly difficult to replay real-world web pages. In Chromium, we have --record-mode and --playback-mode flags for this use case. They put the cache, cookie jar, and some other components into a special mode where everything is aggressively captured and replayed without going to the net. In the case of Firefox, I believe someone at one time implemented a Firefox extension that rewrote pages to capture resources and use local references. Since most websites are not redistributable, it seems like you need some code like Chromium's or Firefox's in WebKit in order to make this proposal work with offline data. - a ___ 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] bugs.webkit.org UI housekeeping
Hopefully not too off-topic, but along lines of bugs UI housekeeping... I'd like a way to CC myself on a bug without spamming everyone on the bug. Some other bug trackers offer a checkbox that can disable email update. Would anyone else find something like that useful? -Tony ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] bugs.webkit.org UI housekeeping
The e-mail notification for CC field changes is (among others) configurable in everyone's Bugzilla preferences. By default, only bug originator and assignee get an e-mail for that. I think that originators generally appreciate any kind of activity on their bugs, even as small as someone adding themselves to the CC list. That makes sense, thanks for the explanation. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New Feature - Resource Timing
On Tue, May 24, 2011 at 8:14 AM, Maciej Stachowiak m...@apple.com wrote: On May 23, 2011, at 8:16 AM, Patrick Mueller wrote: On 5/20/11 12:46 PM, Alexey Proskuryakov wrote: What incentive will users have to enable it? For other privacy sensitive features (be it cookies or geolocation), there is a clear benefit to gain from them. This is a developer-mode feature. There is no direct incentive for end users to enable something like Resource Timing. However, it's not hard to imagine a site suggesting that people could enable Resource Timing, and have that timing information sent back to the site for analysis, much the same way many programs today allow users to opt-in to sending diagnostic information back to a server somewhere. Hi Patrick, I may have misunderstood the feature, but I don't think that is the intent. I believe that Resource Timing and Navigation Timing are meant to be on in a normal user configuration. Websites can then make use of these APIs to get real-world performance data in the field, from users' machines. If the feature was meant to be opt-in and for developers only, then that would greatly reduce my concerns. Perhaps someone more familiar with these APIs can explain the design. Yes, Maciej is correct. The use case is for performance monitoring rather than as a developer tool. In a dev environment, the Inspector already provides all of these details and more. However, a web page's performance characteristics may vary significantly with network conditions, geographic location, browser, OS, hardware, server load etc. A developer may be able to simulate a few of these in a controlled dev environment, but that doesn't necessarily accurately represent what real world users experience. For instance, imagine you invested in a more expensive CDN which claims to serve your static resources closer to your users. It would seem wise to have some way to monitor that this CDN actually improves user performance. That would be difficult to convince yourself of with dev tools alone. Today, many websites employ some form of performance monitoring. The problem is that only a limited picture can be obtained by timing existing events in JS. The intent of this API is to allow websites to obtain a more complete picture of the page's performance. The concern is that this may inadvertently expose side channel information. My hope is that we can trim down the API to the point where there is no new exploitable side channel information so that this can be enabled by default. -Tony ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New Feature - Resource Timing
On Fri, May 20, 2011 at 3:17 AM, Simon Fraser simon.fra...@apple.comwrote: Seem like this new web-facing API would provide more data for sites wanting to do user fingerprinting, even when cookies etc. are disabled. Good point. To my knowledge this is the most thorough explanation of the issue: http://sip.cs.princeton.edu/pub/webtiming.pdf Unfortunately, the techniques mentioned in that paper are all possible without navigation or resource timing. It is also highly unlikely that anything can be done to prevent such attacks (beyond, say, artificially slowing network requests in the same way encryptions algorithms are sometimes slowed). No one has yet identified a new attack vector, but that doesn't mean one doesn't exist. Given the concern, perhaps this feature should have a run time enable guard underneath the ENABLE(WEB_TIMING) compile guard. This would give embedding applications the flexibility to enable/disable via a user preference. Simon On May 19, 2011, at 6:14 PM, James Simonsen wrote: Hello webkit-dev, The W3C Performance WG has been working on a Resource Timing spec. The spec is starting to stabilize and we'd like to start landing it in WebKit too. Resource Timing is a follow up to Navigation Timing, which is already in WebKit. Resource Timing allows site developers to collect detailed network timing information for the subresources they load. The data is exposed through the window.performance namespace and we expect developers to ping this information back to the server with their other analytics data. For security reasons, the spec limits the detailed information to same-origin resources, but there is also a provision for a CORS-like header to allow cross-origin resource timing. Resource Timing will be behind ENABLE(WEB_TIMING) since it relies on some of the same infrastructure as Navigation Timing. We can add an additional ENABLE to keep Resource Timing separate from Navigation Timing if that's desired. The current draft of the Resource Timing API is here: http://w3c-test.org/webperf/specs/ResourceTiming/ A meta-bug to track the necessary work is here: https://bugs.webkit.org/show_bug.cgi?id=61138 Please post any feedback. 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] New Feature - Resource Timing
Presumably the embedding application would need to require explicit user consent to enable the feature. My conclusion was different. Given that the timing based privacy attacks are demonstrable without the interface, I thought it reasonable to enable-by-default with a hidden pref to disable. But this is based on the assumption that we aren't actually exposing any new private information. Am I missing an exploit here? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New Feature - Resource Timing
I've forwarded these questions on to the working group: http://lists.w3.org/Archives/Public/public-web-perf/2011May/0102.html In the meantime, we'll hold off on landing anything until we have satisfactory answers. -Tony On Fri, May 20, 2011 at 6:51 PM, Maciej Stachowiak m...@apple.com wrote: On May 20, 2011, at 10:10 AM, Tony Gentilcore wrote: Presumably the embedding application would need to require explicit user consent to enable the feature. My conclusion was different. Given that the timing based privacy attacks are demonstrable without the interface, I thought it reasonable to enable-by-default with a hidden pref to disable. But this is based on the assumption that we aren't actually exposing any new private information. Am I missing an exploit here? I understand that we have to keep a balance, and statistical fingerprinting is already dismayingly effective without any new features. However, enable[d]-by-default with a hidden pref to disable sounds like an extremely weak approach to protecting user privacy. Is it possible to find experts on the topic of statistical fingerprinting, as well as security experts in general, who could review this API? Things I'd really like to know are: - Does this feature, as designed, increase the effectiveness of user fingerprinting, assuming the user is running something like private browsing or incognito mode, or is regularly deleting site data? The relevant question here is marginal increase in effectiveness - are things worse with this feature than without? - Presumably some known statistical fingerprinting techniques can be mitigated, if not always than at least in private browsing mode. If that was done, then would this timing feature provide an additional fingerprinting vector? - Could this feature directly reveal otherwise hard-to-guess information about users? - Can this feature be used to aid timing-based security attacks? I would really like to see this kind of review done ahead of time and delivered to the Working Group. My worry here is that the feature may have fatal flaws as currently designed, or perhaps even in the basic concept of its functionality. If that's the case, then we'd certainly want to find out before we get locked into it. Perhaps some of the privacy risks can even be mitigated, such as by returning fake or random data in private browsing mode. I can ask some of Apple's security experts to review with a mind to these questions, but I'm wondering if there are other independent experts we could ask. My preference would be to tread very carefully around anything that could be perceived as a privacy risk. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature announcement – Video conferencing and peer-to-peer communication
For those interested, the cover bug for this work is here: https://bugs.webkit.org/show_bug.cgi?id=56459 -Tony On Fri, May 13, 2011 at 8:27 AM, Adam Bergkvist adam.bergkv...@ericsson.com wrote: I want to inform people on this list that we have been doing some early implementation work of the video conferencing and peer-to-peer communication chapter in the HTML spec ( http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#video-conferencing-and-peer-to-peer-communication). This section of the spec is in an early stage and should be considered experimental, but as it becomes more understood, we intend to contribute to the WebKit implementation. Others are also (based on bugs reported) working on this. BR Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Contributors meeting notes
I was sad not to be able to attend the contributors meeting. Did anyone happen to take any notes? -Tony ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SearchBox API
Sorry to resurrect this old thread I presume you resurrected for other reasons, but I'll take the opportunity to give a brief update. The API is now implemented as a V8 extension in Chromium and documented here: http://dev.chromium.org/searchbox ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question regarding priorities of subresource content retrieval
Your test case isn't really about prioritization. The HTML5 spec defines very specifically when parsing must stop. The two main cases are: 1. Waiting for an external script to download 2. Waiting for an external stylesheet to download when any script block is reached In these cases, the parser does not continue parsing the document to discover new subresources to download. However, as an optimization, the PreloadScanner speculatively scans the source (which it is not allowed to parse yet) for any subresources which should probably be downloaded. This way when parsing does continue the resources are already available or at least have a head start. So if we aren't able to scan ahead and at least discover these resources, prioritization is moot. Now, assume we have discovered all subresources on the page and could prioritize them altogether. I'm still not sure I'd buy your argument about resources from another domain being less important. Many sites use CDNs on different domains to download resources. Also, many sites include their JS libraries from common locations. In either of those cases, another domain could be holding the critical blocking resource. Perhaps it is worth experimenting with the heuristic you suggest, but I certainly don't think we can just assert that is the case. On Tue, Feb 8, 2011 at 2:23 AM, Silvio Ventres silvio.vent...@gmail.com wrote: This argument - web developer is to blame for choosing a slow ad/tracking/etc server - is incorrect. Web developers in general do not have any control over the ad provider or, frankly, any other type of external functionality provider. Google Analytics being a good point in case, you would not want most of the world's web pages to suddenly hang if something happens inside Google. The web browser should clearly prioritize developer-controllable resources over ones that are beyond web developer's control. Also, as an application run by the user and not by the developer, the browser should arguably prioritize actual content against pseudo-content which purpose is functionality that is not visibile to the actual user, such as ad/tracker scripts. This actual content has higher probability to be important when sourced from the domain/subdomain of the webpage itself, based on current trends. Domain check is a reasonable approximation that fits both purposes. -- silvio On Tue, Feb 8, 2011 at 5:13 AM, Jerry Seeger vikin...@mac.com wrote: I'm reasonably sure that javascript in the header must be loaded synchronously, as it might affect the rest of the load. This is why tools like YSlow advise Web designers to move javascript loads that are not needed for rendering until after the rest of the page loads. Blocking on loading the css is less clear-cut, as in some cases it could mean several seconds of ugly page. I don't know if it's right or wrong, but a lot of pages out there rely on the CSS being loaded before the page starts to render to avoid terrible layout and the appearance of items meant to be hidden for the seconds it takes the css to load. In general, while things could certainly be improved, it's up to the owner of the page to not rely on a a slow ad server, or build the page so the ads load after the primary content. Jerry Seeger On Feb 7, 2011, at 5:47 PM, Silvio Ventres wrote: IE/Opera are delaying only for 4 seconds, same as Mobile Safari The reason looks to be the url for the script/css. If the url is the same twice, Chrome/Firefox serializes the requests, while IE/Opera/MobileSafari launches both requests simultaneously. Of course, requesting simultaneously doesn't fix anything, as you can see by trying a link-stuffed version at http://solid.eqoppa.com/testlag2.html This one has 45 css and 38 javascript links. It hangs all browsers nicely. The main point here is that it might be acceptable if it's coming from the webpage domain itself. But the links are coming from a completely different place. This is exactly what makes browsing pages with any third-party analytics, tracking or ad addons so slow and frustrating. Fixing priorities in subresource download should make experience considerably more interactive and fun. -- silvio ___ 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] OSX build break after system update
On Wed, Oct 27, 2010 at 10:11 PM, Eric Seidel e...@webkit.org wrote: Can we just include the headers in WebKit? Or find some way to auto-download them? +1 This seems silly. Or certainly requiring an update to http://webkit.org/building/tools.html. In the meantime, there is: https://bugs.webkit.org/show_bug.cgi?id=48423 -eric On Thu, Oct 21, 2010 at 3:56 PM, Tony Gentilcore to...@chromium.org wrote: Quick PSA: if you install the Java for Mac OS X 10.6 Update 3 system update you may start getting build errors like: error: JavaVM/jni.h: No such file or directory The solution is to install Java for Mac OS X 10.6 Update 3 Developer Package from http://connect.apple.com Downloads Java [1]. Thanks andersca for the solution! -Tony [1] This link might work: http://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wo/5.1.17.2.1.3.3.1.0.1.1.0.3.8.3.3.1 ___ 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] OSX build break after system update
Quick PSA: if you install the Java for Mac OS X 10.6 Update 3 system update you may start getting build errors like: error: JavaVM/jni.h: No such file or directory The solution is to install Java for Mac OS X 10.6 Update 3 Developer Package from http://connect.apple.com Downloads Java [1]. Thanks andersca for the solution! -Tony [1] This link might work: http://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wo/5.1.17.2.1.3.3.1.0.1.1.0.3.8.3.3.1 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] SearchBox API
Hi All, We are working on adding instant search integration to Chrome. This requires a DOM API which only the default search provider has permission to access. As some of you may have seen, earlier this week I sent a proposal for such an API to the WHATWG [1]. Is this something that other ports might be interested in supporting in the future? In any case, are there objections to beginning to land this under flag guard and vendor prefix? -Tony [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-October/028818.html ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SearchBox API
On Fri, Oct 15, 2010 at 10:28 AM, Darin Fisher da...@chromium.org wrote: I think we're just coming at this from the point of view of trying to avoid UA-specific APIs exposed to web content. It seems risky to build APIs outside of WebKit that may be adopted by other UAs. We can certainly revisit this if that ever becomes reality. (Our current implementation exists on window.chrome.* by the way.) -Darin On Fri, Oct 15, 2010 at 10:24 AM, Eric Seidel e...@webkit.org wrote: http://googlesystem.blogspot.com/2010/09/instant-search-in-google-chrome.html would be more compelling with a video. :) http://www.youtube.com/watch?v=tefRwthQaes shows an old version where the content didn't adjust to the dropdown size. You can play w/ it yourself on a windows dev channel build. I agree with Darin, this sounds like Browser-exposed DOM API. Not something that WebKit has any business adding. -eric On Fri, Oct 15, 2010 at 10:10 AM, Darin Adler da...@apple.com wrote: On Oct 15, 2010, at 10:00 AM, Tony Gentilcore wrote: In any case, are there objections to beginning to land this under flag guard and vendor prefix? Yes, I do have an objection. Browser-specific API can be injected by the browser and doesn’t need to be built into WebKit. Safari already has some DOM API accessible only to search providers. WebKit has an architecture that allows this to be done without WebKit code changes. I suggest we put this feature in browsers, not the engine. Okie. It sounds like the answer to my first question is an implied no. I'll keep in it Chrome for now. If this is ever something that other ports are interested in supporting, I'll still be happy to do the upstreaming work. -- 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 ___ 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] When to use FastAllocBase?
For general reference, when is it appropriate to use FastAllocBase? If you subclass RefCountedT or Noncopyable, which is very common, you pick up FastAllocBase. So, my naive guess is that any class/struct which doesn't pick up FastAllocBase through its inheritance chain should subclass it directly. Is that a reasonable guideline? Thanks, -Tony ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] When to use FastAllocBase?
Thanks for the responses. That clears everything up for me. I would recommend we add something to http://webkit.org/coding/coding-style.html, but it sounds like we shouldn't do anything at this point since everything is change. On Mon, Oct 4, 2010 at 11:46 AM, Darin Adler da...@apple.com wrote: On Oct 4, 2010, at 11:31 AM, Tony Gentilcore wrote: If you subclass RefCountedT or Noncopyable, which is very common, you pick up FastAllocBase. Yes, so in those cases you don’t want to use it. So, my naive guess is that any class/struct which doesn't pick up FastAllocBase through its inheritance chain should subclass it directly. Is that a reasonable guideline? That’s OK, but: 1) FastAllocBase has been causing object size bloat, so we are planning to switch from base classes to macros. See bug 42998 https://bugs.webkit.org/show_bug.cgi?id=42998. 2) If the object will not ever be allocated with new, there is no benefit to deriving from FastAllocBase. 3) Our original plan was to that on platforms where ENABLE_GLOBAL_FASTMALLOC_NEW, such as Mac OS X, we would change the operator new to check at runtime and immediately assert in debug builds if someone forgot to use FastAllocBase. But as you can see if you look at FastMalloc.h, this has not been done yet. So for the moment it’s fine to follow the guideline you mention, but (1) will change how we do it soon, (2) is worth considering, and (3) will eventually make the guideline clearer than it is now because we’ll notice when we do it wrong! -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Getting rid of WebCore.xcodeproj developmentRegion diff
Just a thought. Would it be too aggressive/premature to add a style rule requiring the Xcode 3.2.3+ behavior? That would unfortunately mean that users of older versions would have to manually edit the file to keep the style checker happy. On Tue, Aug 17, 2010 at 11:28 AM, Darin Adler da...@apple.com wrote: It’s the Xcode team’s fault, caused by people using different versions of Xcode. Short term, I don’t know any way to make it go away. Long term it will disappear once all contributors are using Xcode 3.2.3 or newer. -- 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] Leopard Release Builder -- Slave Lost
Looks like the slave is back now. But there are ~90 pending builds: http://build.webkit.org/builders/Leopard%20Intel%20Release%20(Tests) For future reference, I'm curious if it is safe to cancel some older builds so that it will catch up. On Tue, Aug 3, 2010 at 11:37 AM, Eric Seidel e...@webkit.org wrote: http://build.webkit.org/builders/Leopard%20Intel%20Release%20(Tests) We lost the slave over 3 days ago. :( (The tree is also generally on fire right now...) -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] Updating the tradition for new reviewer blog posts
The Surfin' Safari blog seems to have fairly wide readership in the web dev community. Google Reader reports 35k Reader subscribers. For comparison: blog.chromium.org has 17k and blog.mozilla.com has 10k. However, the last post with descriptive content was back on April 18th. Since that post, we've written 8 X is a now a WebKit reviewer posts. One recent commenter said: *I don’t suppose there’s anything more interesting going on in WebKit land worth blogging about, is there? So-and-so is a new WebKit reviewer isn’t nearly as interesting as whatever new hotness is coming down the pipe. And I know I’m not the only one who thinks so… Feel like blogging about WebKit awesomeness?* I propose we increase the amount of blogging about WebKit awesomeness by changing the tradition for new reviewer posts. Instead of defaulting to: * So-and-so is now a WebKit reviewer* * Posted by Someone-else So-and-so has worked on awesome-feature or awesome-infrastructure...* We encourage (or just allow?) a format more like: * How awesome-infrastructure works* * Posted by So-and-so, the latest WebKit reviewer Here's my description of how awesome-infrastructure works in WebKit...* * * * -OR- * * ** Awesome-feature is the new hotness* * Posted by So-and-so, the latest WebKit reviewer Web developers can now use awesome-feature. Here's how it works...* Thoughts? -Tony ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Snow Leopard Bot went down
No theories. But another data point; Tiger started doing the same a few revisions earlier: /Volumes/Data/WebKit-BuildSlave/tiger-intel-release/build/WebKit/mac/WebView/WebView.mm: In function 'void -[WebView(WebPrivate) _commonInitializationWithFrameName:groupName:usesDocumentViews:](WebView*, objc_selector*, NSString*, NSString*, BOOL)': /Volumes/Data/WebKit-BuildSlave/tiger-intel-release/build/WebKit/mac/WebView/WebView.mm:628: internal compiler error: Segmentation fault On Fri, Jul 9, 2010 at 3:13 PM, Eric Seidel e...@webkit.org wrote: /Volumes/Data/WebKit-BuildSlave/snowleopard-intel-release/build/WebCore/config.h:212: fatal error: error writing to -: Broken pipe compilation terminated. i686-apple-darwin10-gcc-4.2.1: Internal error: Segmentation fault (program as) Please submit a full bug report. See URL:http://developer.apple.com/bugreporter for instructions. http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20(Build)/builds/13344/steps/compile-webkit/logs/stdio Any theories? ___ 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] Frustrated at inconsiderate behavior
On Wed, Jul 7, 2010 at 6:50 PM, Mo, Zhenyao zhen...@gmail.com wrote: Maybe I should complain this in a different threads, but recently the commit bot waiting time is way too long. Several times a patch of mine got the r+ and cq+ and it landed two days later. This is really frustrating. I am very tempted to use svn directly to commit patches, but that means the patch only gets tested in my local environments. Like one time my patch breaks the leopard bot, turns out the failed test is skipped on leopard, which is exactly my OS. If I land it through the commit bots, I could identify the issue earlier. I agree they are closely related. A greener tree means a faster commit queue and a faster commit queue means less people subvert it and break the tree. The hard problem is figuring out how to fix the incentives so subverting the queue isn't so desirable. There is also a smaller but more concrete problem. Older bugs cut in front of newer bugs in the commit queue. So when the queue is moving slowly, patches with recent bug IDs could spend a long time getting bumped before finally landing. https://bugs.webkit.org/show_bug.cgi?id=41791 If there is any way to improve the situation, I'd really appreciate it. mo On Wed, Jul 7, 2010 at 12:47 AM, Adam Barth aba...@webkit.org wrote: If you're tired of my complaining about the tree being red, you can skip this message. Today Alexey checked in http://trac.webkit.org/changeset/62576, which broke two tests on every port. 12 hours later, these failures remained in the tree until I cleaned them up. This mess could have been avoided in a number of ways: 1) He could have run-webkit-tests before committing his change. 2) If he didn't have time to run the tests locally, he could have used the commit-queue to run-webkit-tests before it landed his patch. 3) He could have looked at the tree when sheriff-bot informed him that he might have broken Leopard Intel Debug by pinging him in #webkit and commenting on his bug: https://bugs.webkit.org/show_bug.cgi?id=41156#c8. Is this acceptable behavior? http://webkit.org/coding/contributing.html clearly says to run the layout tests using the run-webkit-tests script and make sure they all pass. That page also says: [[ In either case, your responsibility for the patch does not end with the patch landing in the tree. There may be regressions from your change or additional feedback from reviewers after the patch has landed. You can watch the tree at build.webkit.org to make sure your patch builds and passes tests on all platforms. It is your responsibility to be available should regressions arise and to respond to additional feedback that happens after a check-in. ]] Are there consequences for breaking these rules? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Frustrated at inconsiderate behavior
On Wed, Jul 7, 2010 at 7:22 PM, James Robinson jam...@google.com wrote: On Wed, Jul 7, 2010 at 7:19 PM, Oliver Hunt oli...@apple.com wrote: On Jul 7, 2010, at 7:16 PM, Tony Gentilcore wrote: On Wed, Jul 7, 2010 at 6:50 PM, Mo, Zhenyao zhen...@gmail.com wrote: Maybe I should complain this in a different threads, but recently the commit bot waiting time is way too long. Several times a patch of mine got the r+ and cq+ and it landed two days later. This is really frustrating. I am very tempted to use svn directly to commit patches, but that means the patch only gets tested in my local environments. Like one time my patch breaks the leopard bot, turns out the failed test is skipped on leopard, which is exactly my OS. If I land it through the commit bots, I could identify the issue earlier. I agree they are closely related. A greener tree means a faster commit queue and a faster commit queue means less people subvert it and break the tree. The hard problem is figuring out how to fix the incentives so subverting the queue isn't so desirable. What do you mean by subvert the queue? The commit queue is a tool to streamline commits from contributors who do not have commit access to the repository. If you have the ability to commit you should not be using the commit queue to land your patches. That's not my understanding of the commit queue. I use the commit queue to land my patches when possible so that the patch receives further testing before it hits the tree and potentially affects a large number of contributors. Why do you think this is a bad idea? Is this preference codified somewhere (formally or informally)? Interesting. I'm a very new committer and it is possible I've completely misunderstood it. I thought of it as a useful tool to help make sure our patches don't break the tree. But given James' response I'm now very interested to hear what others think. - James --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Questions of a new committer
Is there any policy or guideline regarding when it is appropriate to use the commit queue vs landing directly? I feel like there is an unfortunate positive feedback loop right now: 1. Commit queue gets slightly backed up either due to a breakage or just heavy volume. 2. Because the queue is backed up, it is more tempting to land directly. 3. Directly landed patches are more likely to break the tree and the new breakage backs up the queue even more. 4. Goto #2. Long queues punish developers not because of the wait for the patch to land, but because those patches are more likely to have merge conflicts. So the incentive seems to be to land without the queue. I'm just curious if this has been brought up before and if folks more experienced than myself have ideas about how we could improve this. Tony ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ask for WTF introduction
There's an excellent doc on some of WTF's smart pointers: http://webkit.org/coding/RefPtr.html I'm interested to hear if there are any other references out there too. On Fri, Jun 4, 2010 at 7:45 PM, Eric Zhou engle...@gmail.com wrote: Hi all, Could anyone give me some references about WTF, like tutorials or introduction? Thanks BR/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
Re: [webkit-dev] prepare-Changelog crashing on cygwin
On Mon, May 10, 2010 at 1:07 PM, Eric Seidel e...@webkit.org wrote: Is this caused by the base load address of both perl and svn conflicting/overlapping? (I don't really know how CYGWIN works.) I'm by no means a cygwin expert. I just happened to run into the same problem last week. This thread is where I found that solution (first suggested by evan): http://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/bac1846c2678152d/4b9548cdd7214e4e http://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/bac1846c2678152d/4b9548cdd7214e4e Is this something we should detect in our scripts and warn about? If that is possible, it would be a great win. Both John and I separately wasted a lot of time on this. On Mon, May 10, 2010 at 12:41 PM, John Abd-El-Malek j...@google.com wrote: btw, I finally solved this. credit to tonyg: 1) close cygwin 2) C:\cygwin\binash rebaseall On Mon, May 10, 2010 at 12:20 PM, Eric Seidel e...@webkit.org wrote: On Mon, May 10, 2010 at 11:31 AM, Eric Seidel esei...@google.com wrote: I have seen this on the win-ews ec2 instance. On May 10, 2010 1:35 PM, John Abd-El-Malek j...@google.com wrote: After reimaging my Windows 7 machine, prepare-Changelog always crashes for me now. It seems to have problems running svn diff. I installed cygwin through the installer on webkit.org. I don't have any anti-virus programs running, and DEP is turned off for cygwin.exe and svn.exe. Has anyone else seen this? Thanks, John jabdelma...@jabdelmalek0-w /cygdrive/d/WebKit/WebKit/chromium $ ../../WebKitTools/Scripts/prepare-ChangeLog Running status to find changed, added, or removed files. ? svn.exe.stackdump Reviewing diff to determine which lines changed. 0 [main] svn 1652 exception::handle: Exception: STATUS_ACCESS_VIOLATION 1873 [main] svn 1652 open_stackdumpfile: Dumping stack trace to svn.exe.stackdump 0 [main] svn 1652 exception::handle: Exception: STATUS_ACCESS_VIOLATION 1873 [main] svn 1652 open_stackdumpfile: Dumping stack trace to svn.exe.stackdump 0 [main] svn 7828 exception::handle: Exception: STATUS_ACCESS_VIOLATION 0 [main] svn 7828 exception::handle: Exception: STATUS_ACCESS_VIOLATION 1863 [main] svn 7828 open_stackdumpfile: Dumping stack trace to svn.exe.stackdump 1863 [main] svn 7828 open_stackdumpfile: Dumping stack trace to svn.exe.stackdump 0 [main] svn 6132 exception::handle: Exception: STATUS_ACCESS_VIOLATION 1818 [main] svn 6132 open_stackdumpfile: Dumping stack trace to svn.exe.stackdump 0 [main] svn 6132 exception::handle: Exception: STATUS_ACCESS_VIOLATION 1818 [main] svn 6132 open_stackdumpfile: Dumping stack trace to svn.exe.stackdump 1 [main] svn 15284 exception::handle: Exception: STATUS_ACCESS_VIOLATION 1547 [main] svn 15284 open_stackdumpfile: Dumping stack trace to svn.exe.stackdump 1 [main] svn 15284 exception::handle: Exception: STATUS_ACCESS_VIOLATION 1547 [main] svn 15284 open_stackdumpfile: Dumping stack trace to svn.exe.stackdump 0 [main] svn 9296 exception::handle: Exception: STATUS_ACCESS_VIOLATION 2474 [main] svn 9296 open_stackdumpfile: Dumping stack trace to svn.exe.stackdump 2474 [main] svn 9296 open_stackdumpfile: Dumping stack trace to svn.exe.stackdump 0 [main] svn 10444 exception::handle: Exception: STATUS_ACCESS_VIOLATION 2067 [main] svn 10444 open_stackdumpfile: Dumping stack trace to svn.exe.stackdump 0 [main] svn 10444 exception::handle: Exception: STATUS_ACCESS_VIOLATION 2067 [main] svn 10444 open_stackdumpfile: Dumping stack trace to svn.exe.stackdump 0 [main] svn 12428 exception::handle: Exception: STATUS_ACCESS_VIOLATION 1925 [main] svn 12428 open_stackdumpfile: Dumping stack trace to svn.exe.stackdump 0 [main] svn 12428 exception::handle: Exception: STATUS_ACCESS_VIOLATION 1925 [main] svn 12428 open_stackdumpfile: Dumping stack trace to svn.exe.stackdump 0 [main] svn 3940 exception::handle: Exception: STATUS_ACCESS_VIOLATION 0 [main] svn 3940 exception::handle: Exception: STATUS_ACCESS_VIOLATION 1538 [main] svn 3940 open_stackdumpfile: Dumping stack trace to svn.exe.stackdump 1538 [main] svn 3940 open_stackdumpfile: Dumping stack trace to svn.exe.stackdump 0 [main] svn 15008 exception::handle: Exception: STATUS_ACCESS_VIOLATION 2251 [main] svn 15008 open_stackdumpfile: Dumping stack trace to svn.exe.stackdump 2251 [main] svn 15008 open_stackdumpfile: Dumping stack trace to svn.exe.stackdump 0 [main] svn 14496 exception::handle: Exception: STATUS_ACCESS_VIOLATION 1796 [main] svn 14496 open_stackdumpfile: Dumping stack trace to
Re: [webkit-dev] webkit-patch, check-webkit-style and git now support --squash and --git-commit
I'm just in the process of converting to git, but this looks amazing! It would be really helpful for me if http://trac.webkit.org/wiki/UsingGitWithWebKit had a section that explains the flow for using webkit-patch with git. On Mon, Apr 26, 2010 at 1:20 PM, Kenneth Christiansen kenneth.christian...@openbossa.org wrote: Nice work Ojan, Will you make webkit-patch apply-attachment understand patches doing renames/mv created with git format-patch? That would be really useful. Cheers, Kenneth On Mon, Apr 26, 2010 at 2:55 PM, Ojan Vafai o...@chromium.org wrote: The behavior of git and webkit-patch changed with http://trac.webkit.org/changeset/58261. Many webkit-patch commands (e.g. upload and land) and check-webkit-style now take --squash and --git-commit arguments. --git-commit: upload, commit, check-style, etc on the given git commit(s). Commits can be specified as single commits (e.g. HEAD^) or mulitiple (e.g. HEAD~2..HEAD). check-webkit-style's sense of --git-commit is no longer all patches since the commit and --git-since is removed. The equivalent to the old check-webkit-style behavior is --git-commit=HEAD~2.. instead of just using HEAD~2. --squash: Treat all changes in the local branch as a single patch (local commits + working copy changes). Doesn't actually modify your tree until you land, at which point it squashes all local changes into a single local commit and then lands that. --no-squash: Treat all changes as separate. This is essentially just git svn dcommit. Each local change is committed separately. If you leave out --squash and --no-squash, then something resembling the old behavior is used. old-behavior: upload, diff, create-patch, etc. only considered working-copy changes and land will commit working-copy changes and then commit each local commit separately. new-behavior: is roughly like the above, except if there's only a single local commit and no working-copy changes, then the commands will work on that single local commit and otherwise raise an error. Eventually, I'd like to make --squash the default, but I want this to bake and get some usage before flipping that switch. Finally, if you get sick of typing --squash or --no-squash, you can set the webkit-patch.squash git config parameter to true/false. Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org ___ 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] Advise on spellchecker bug
I'm new to WebKit, so apologies in advance for my ignorance. There is a chromium bug that we don't update the spelling markers when spell checking is toggled or the language is changed (http://crbug.com/21225). I have a fix ready for this which simply re-checks the field upon toggle. But this step could either be done in the WebCore Editor or just in the chromium port. So I have two questions: 1. Is this port specific? Safari's spell check toggle menu item says Check document while typing, but Chrome's says Check spelling in this field. This makes me think that Chrome users expect the markers to be refreshed, but Safari users may not. 2. Where is the best place to add a test for my fix? It doesn't seem to be possible to test this through a LayoutTest. If the answer to #1 is that this is port-specific behavior, then I can add a chromium/tests. If this is not port-specific, then any advise on how to test would be appreciated. Thanks, Tony ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
