Re: [webkit-dev] beforeload link (esp rel prefetch)
On 13.01.2011 07:42, Darin Fisher wrote: Firefox definitely supports rel=prefetch in HTTP Link headers. I believe it also supports other rel types, like stylesheet. The rel=subresource bit is something new. Yes, stylesheet is supported. For subresource, I *really* would like to see a proper spec. Supporting the Link header enables web servers to inject link tags without modifying the document, which can be useful, especially for intermediaries. Indeed. Best regards, Julian ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] proposal: pass --exit-after-n-failures 500 to old-run-webkit-tests on the bots
Hi WebKit developers, Yesterday http://trac.webkit.org/changeset/75682 made all layout tests fail and buildbots sick, because of an accidentally committed debug puts(). The size of results for ~22000 failing layout tests is more than 100Mb. This very big filesize is absolutely unnecessary, storage and network killer. I propose to pass --exit-after-n-failures 500 option to the old-run-webkit-tests on the buildbots to make buildbot master and slaves happier. 500 should be more than enough for online rebaselining and avoid 100Mb sized result files. I filed a bug for it: https://bugs.webkit.org/show_bug.cgi?id=52364 Any objections or seconder for this change? br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] beforeload link (esp rel prefetch)
12.01.2011, в 22:42, Darin Fisher написал(а): Supporting the Link header enables web servers to inject link tags without modifying the document, which can be useful, especially for intermediaries. I'm wondering what the use cases are. To me, adding a way for metadata to change document behavior sounds like a misfeature - it adds significant complexity to the system, while taking away existing functionality. As a specific example discussed in this thread, we'd break some browser extensions like Incognito if resource loading could bypass onbeforeload. As another example, we'd break base element. Historically, attempts to use HTTP metadata with HTML caused significant trouble - user agents don't even agree on Content-Type handling, and more complicated features like Vary pretty much don't work at all. Is there a reason to believe that fetching resources via Link will be anything more than a source of incompatibilities and security bugs? - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] beforeload link (esp rel prefetch)
On 13.01.2011 18:02, Alexey Proskuryakov wrote: 12.01.2011, в 22:42, Darin Fisher написал(а): Supporting the Link header enables web servers to injectlink tags without modifying the document, which can be useful, especially for intermediaries. I'm wondering what the use cases are. To me, adding a way for metadata to change document behavior sounds like a misfeature - it adds significant complexity to the system, while taking away existing functionality. As a specific example discussed in this thread, we'd break some browser extensions like Incognito if resource loading could bypass onbeforeload. As another example, we'd breakbase element. Well, there are document types where you *can't* inline the metadata. Historically, attempts to use HTTP metadata with HTML caused significant trouble - user agents don't even agree on Content-Type handling, and more complicated features like Vary pretty much don't work at all. Is there a reason to believe that fetching resources via Link will be anything more than a source of incompatibilities and security bugs? We should distinguish between the act of declaring the link, and the moment where a potential fetch actually happens (it doesn't always happen, after all). I agree that stuffing things just to get a fetch to happen earlier maybe a premature optimization. Best regards, Julian ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] proposal: pass --exit-after-n-failures 500 to old-run-webkit-tests on the bots
Seems reasonable. On Thu, Jan 13, 2011 at 8:18 AM, Osztrogonac Csaba o...@inf.u-szeged.huwrote: Hi WebKit developers, Yesterday http://trac.webkit.org/changeset/75682 made all layout tests fail and buildbots sick, because of an accidentally committed debug puts(). The size of results for ~22000 failing layout tests is more than 100Mb. This very big filesize is absolutely unnecessary, storage and network killer. I propose to pass --exit-after-n-failures 500 option to the old-run-webkit-tests on the buildbots to make buildbot master and slaves happier. 500 should be more than enough for online rebaselining and avoid 100Mb sized result files. I filed a bug for it: https://bugs.webkit.org/show_bug.cgi?id=52364 Any objections or seconder for this change? 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
Re: [webkit-dev] beforeload link (esp rel prefetch)
13.01.2011, в 09:14, Julian Reschke написал(а): I'm wondering what the use cases are. To me, adding a way for metadata to change document behavior sounds like a misfeature - it adds significant complexity to the system, while taking away existing functionality. As a specific example discussed in this thread, we'd break some browser extensions like Incognito if resource loading could bypass onbeforeload. As another example, we'd breakbase element. Well, there are document types where you *can't* inline the metadata. Indeed, and I don't have anything against metadata as long as it doesn't directly modify actual data. For example, Last-Modified and Cache-Control are quite obvious example of what can be in HTTP headers. Despite the practical/historical difficulties that I mentioned with Content-Type, it's arguably a valid example of metadata, too. Subresource references on the other hand are a part of a document, not of its metadata. Am I just missing a reason why one would want to prefetch subresources for a JPEG image? We should distinguish between the act of declaring the link, and the moment where a potential fetch actually happens (it doesn't always happen, after all). I agree that stuffing things just to get a fetch to happen earlier maybe a premature optimization. Optimizing prefetch to start before actual document data arrives is highly controversial, but I believe that it's the primary reason why we're considering the Link header implementation. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] [Qt] prefix on cross-platform bugs
Recently, a large number of bugs have been migrated from Nokia internal tracker to webkit.org Bugzilla. I think that this is a great thing to do, and I would like to request an amendment to the process. These bugs all have [Qt] in title, meaning that many developers won't read the bug or any patches attached to it. However, it is often known that the bug is not limited to Qt - some of these mention that the same happens in Safari. Artificially limiting the audience in this way is not good. Would it be possible to correct this, at least for future bugs, but ideally for the ones filed recently, too? - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] beforeload link (esp rel prefetch)
On Thursday 13 January 2011 17:02:15 Alexey Proskuryakov wrote: As a specific example discussed in this thread, we'd break some browser extensions like Incognito if resource loading could bypass onbeforeload. Could you elaborate on this a bit? I don't understand the potential breakage. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [Qt] prefix on cross-platform bugs
On Thu, Jan 13, 2011 at 8:07 PM, Alexey Proskuryakov a...@webkit.org wrote: Recently, a large number of bugs have been migrated from Nokia internal tracker to webkit.org Bugzilla. I think that this is a great thing to do, and I would like to request an amendment to the process. These bugs all have [Qt] in title, meaning that many developers won't read the bug or any patches attached to it. However, it is often known that the bug is not limited to Qt - some of these mention that the same happens in Safari. Artificially limiting the audience in this way is not good. Would it be possible to correct this, at least for future bugs, but ideally for the ones filed recently, too? We use the tag Qt for bugs that are related to the project. The [Qt] in the title should be used only for Qt specific bugs as you said. We remove [Qt] from the title when bugs are not Qt specific. I think those bugs imported from the Qt bugtracker are just imported automatically and nobody looked at them. I will be careful about that when triaging future bugs. cheers, Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] beforeload link (esp rel prefetch)
13.01.2011, в 11:34, Robert Hogan написал(а): As a specific example discussed in this thread, we'd break some browser extensions like Incognito if resource loading could bypass onbeforeload. Could you elaborate on this a bit? I don't understand the potential breakage. Privacy enhancing extensions such as this one block access to cross-domain subresources from sites known for pervasive user tracking. If some subresources avoid beforeload, they won't be blocked, and users will be tracked. I would expect that whatever an extension or a Web site wants to do with beforeload, it trusts that there is no bypass such as the Link header. Obviously, nothing will change in practice until sites actually start using the Link header. But widespread use of Link is something we should plan for if we're going to support it. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [Qt] prefix on cross-platform bugs
13.01.2011, в 11:42, Benjamin написал(а): We remove [Qt] from the title when bugs are not Qt specific. Personally, I use an RSS feed for Bugzilla, so if I gloss over a [Qt] bug initially, I won't see it even after it loses the [Qt] prefix. But I think that most people have a different workflow, and will be fully served if [Qt] is removed by the time a patch goes to review. 13.01.2011, в 12:12, prasad.adimu...@nokia.com написал(а): Going forward all errors in webkit will be reported without the [Qt] prefix in the title, which would make these errors visible to large set of audience. Having a prefix on bugs that are clearly unique to a platform is good, as it actually helps people like myself save some time by not reading them. That's of course not something that can be easily automated, and sometimes you don't know where the problem is until a fix is ready. So while we should try to make iterative improvements, there is no expectation of getting this 100% right. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [Qt] prefix on cross-platform bugs
On Thu, Jan 13, 2011 at 9:12 PM, prasad.adimu...@nokia.com wrote: As per the feedback from Alexey Benjamin, had a brief chat with Joel and have come up with this suggestion. Going forward all errors in webkit will be reported without the [Qt] prefix in the title, which would make these errors visible to large set of audience. I think that would be pretty annoying for other ports. If you know what you are doing, sure, drop the [Qt] prefix when the bug is not Qt specific. Otherwise please follow http://trac.webkit.org/wiki/QtWebKitBugs Some bugs report are really bad, I do not want to annoy everyone because we are using WebKit's bugzilla as our only bug tracker for WebKit. We triage bugs regularly. Usually new bugs do not have the [Qt] prefix erroneously for more than a week. cheers, Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] proposal: pass --exit-after-n-failures 500 to old-run-webkit-tests on the bots
I would opt for a lower limit, but 500 is certainly better than no limit. :) I would certainly r+ any such change you were to send my way! -eric On Thu, Jan 13, 2011 at 9:38 AM, Ojan Vafai o...@chromium.org wrote: Seems reasonable. On Thu, Jan 13, 2011 at 8:18 AM, Osztrogonac Csaba o...@inf.u-szeged.hu wrote: Hi WebKit developers, Yesterday http://trac.webkit.org/changeset/75682 made all layout tests fail and buildbots sick, because of an accidentally committed debug puts(). The size of results for ~22000 failing layout tests is more than 100Mb. This very big filesize is absolutely unnecessary, storage and network killer. I propose to pass --exit-after-n-failures 500 option to the old-run-webkit-tests on the buildbots to make buildbot master and slaves happier. 500 should be more than enough for online rebaselining and avoid 100Mb sized result files. I filed a bug for it: https://bugs.webkit.org/show_bug.cgi?id=52364 Any objections or seconder for this change? 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
Re: [webkit-dev] beforeload link (esp rel prefetch)
2011/1/13 Darin Fisher da...@chromium.org: Supporting the Link header enables web servers to inject link tags without modifying the document, which can be useful, especially for intermediaries. That sounds like a great reason not to support this feature. Why would we want to make the web more unpredictable and harder to understand? From prefetching perspective this has little or no value. When we get the response header we are generally milliseconds away from parsing the real document text and requesting the linked resources properly. antti ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] proposal: pass --exit-after-n-failures 500 to old-run-webkit-tests on the bots
There are legit changes that cause hundreds of tests to fail due to needing new baselines (e.g. any skia change), so 500 seems about right to me. On Thu, Jan 13, 2011 at 1:38 PM, Eric Seidel e...@webkit.org wrote: I would opt for a lower limit, but 500 is certainly better than no limit. :) I would certainly r+ any such change you were to send my way! -eric On Thu, Jan 13, 2011 at 9:38 AM, Ojan Vafai o...@chromium.org wrote: Seems reasonable. On Thu, Jan 13, 2011 at 8:18 AM, Osztrogonac Csaba o...@inf.u-szeged.hu wrote: Hi WebKit developers, Yesterday http://trac.webkit.org/changeset/75682 made all layout tests fail and buildbots sick, because of an accidentally committed debug puts(). The size of results for ~22000 failing layout tests is more than 100Mb. This very big filesize is absolutely unnecessary, storage and network killer. I propose to pass --exit-after-n-failures 500 option to the old-run-webkit-tests on the buildbots to make buildbot master and slaves happier. 500 should be more than enough for online rebaselining and avoid 100Mb sized result files. I filed a bug for it: https://bugs.webkit.org/show_bug.cgi?id=52364 Any objections or seconder for this change? 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
Re: [webkit-dev] proposal: pass --exit-after-n-failures 500 to old-run-webkit-tests on the bots
I mean, we could also have it always stop after 5 crashes, but default to 500 for failures or something. Failures (with the exception of timeouts) don't really take that much time. -eric On Thu, Jan 13, 2011 at 1:51 PM, Ojan Vafai o...@chromium.org wrote: There are legit changes that cause hundreds of tests to fail due to needing new baselines (e.g. any skia change), so 500 seems about right to me. On Thu, Jan 13, 2011 at 1:38 PM, Eric Seidel e...@webkit.org wrote: I would opt for a lower limit, but 500 is certainly better than no limit. :) I would certainly r+ any such change you were to send my way! -eric On Thu, Jan 13, 2011 at 9:38 AM, Ojan Vafai o...@chromium.org wrote: Seems reasonable. On Thu, Jan 13, 2011 at 8:18 AM, Osztrogonac Csaba o...@inf.u-szeged.hu wrote: Hi WebKit developers, Yesterday http://trac.webkit.org/changeset/75682 made all layout tests fail and buildbots sick, because of an accidentally committed debug puts(). The size of results for ~22000 failing layout tests is more than 100Mb. This very big filesize is absolutely unnecessary, storage and network killer. I propose to pass --exit-after-n-failures 500 option to the old-run-webkit-tests on the buildbots to make buildbot master and slaves happier. 500 should be more than enough for online rebaselining and avoid 100Mb sized result files. I filed a bug for it: https://bugs.webkit.org/show_bug.cgi?id=52364 Any objections or seconder for this change? 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
Re: [webkit-dev] proposal: pass --exit-after-n-failures 500 to old-run-webkit-tests on the bots
We already have it stop after a much smaller number of crashes/timeouts. So we're just talking about failures here. On Thu, Jan 13, 2011 at 2:11 PM, Eric Seidel e...@webkit.org wrote: I mean, we could also have it always stop after 5 crashes, but default to 500 for failures or something. Failures (with the exception of timeouts) don't really take that much time. -eric On Thu, Jan 13, 2011 at 1:51 PM, Ojan Vafai o...@chromium.org wrote: There are legit changes that cause hundreds of tests to fail due to needing new baselines (e.g. any skia change), so 500 seems about right to me. On Thu, Jan 13, 2011 at 1:38 PM, Eric Seidel e...@webkit.org wrote: I would opt for a lower limit, but 500 is certainly better than no limit. :) I would certainly r+ any such change you were to send my way! -eric On Thu, Jan 13, 2011 at 9:38 AM, Ojan Vafai o...@chromium.org wrote: Seems reasonable. On Thu, Jan 13, 2011 at 8:18 AM, Osztrogonac Csaba o...@inf.u-szeged.hu wrote: Hi WebKit developers, Yesterday http://trac.webkit.org/changeset/75682 made all layout tests fail and buildbots sick, because of an accidentally committed debug puts(). The size of results for ~22000 failing layout tests is more than 100Mb. This very big filesize is absolutely unnecessary, storage and network killer. I propose to pass --exit-after-n-failures 500 option to the old-run-webkit-tests on the buildbots to make buildbot master and slaves happier. 500 should be more than enough for online rebaselining and avoid 100Mb sized result files. I filed a bug for it: https://bugs.webkit.org/show_bug.cgi?id=52364 Any objections or seconder for this change? 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
Re: [webkit-dev] beforeload link (esp rel prefetch)
Thanks everyone for your replies on link headers and rel types. Mike Belshe from Chrome team put together a spec for these as part of Server Hints for SPDY. His server hint information is at: https://sites.google.com/a/chromium.org/dev/spdy/link-headers-and-server-hint, and link rel=subresource is at https://sites.google.com/a/chromium.org/dev/spdy/link-headers-and-server-hint/link-rel-subresource. The bottom line for rel=subresource is that we've found in early experiments that some page loads, especially of pages with dynamic content, are sped up by 15-20%; it's much more than mere milliseconds that we're talking about here. I'd like to do more experimentation with this, and to continue this we'd like to both have this rel type (with its prioritization) and the Link header (with its early arrival). Link rel types significantly change the semantics of each link. rel=stylesheet changes the HTML page's presentation, and in bug 20018, Alexey raised some good points about how this affects saving web pages, and I think these rel types in an HTTP header are justifiably more controversial. But that having been said, the rel types prefetch, subresource, dns-prefetch are basically network level; they are instructions about cache seeding. No resultant document should view differently based on these headers; only faster. I agree that beforeload support could be more pervasive than it is today. The exclusion of prefetch, icon and dns-prefetch from beforeload events bears revisiting. But are these insurmountable? Currently the bug up for review, bug 51941 doesn't remove beforeload handling from anything that had it. The semantics of beforeload handlers for link headers wrt extensions bear some thought, but I suspect these can be solved: can we create another bug for adding this support? - Gavin On 13 January 2011 12:48, Alexey Proskuryakov a...@webkit.org wrote: 13.01.2011, в 09:14, Julian Reschke написал(а): I'm wondering what the use cases are. To me, adding a way for metadata to change document behavior sounds like a misfeature - it adds significant complexity to the system, while taking away existing functionality. As a specific example discussed in this thread, we'd break some browser extensions like Incognito if resource loading could bypass onbeforeload. As another example, we'd breakbase element. Well, there are document types where you *can't* inline the metadata. Indeed, and I don't have anything against metadata as long as it doesn't directly modify actual data. For example, Last-Modified and Cache-Control are quite obvious example of what can be in HTTP headers. Despite the practical/historical difficulties that I mentioned with Content-Type, it's arguably a valid example of metadata, too. Subresource references on the other hand are a part of a document, not of its metadata. Am I just missing a reason why one would want to prefetch subresources for a JPEG image? We should distinguish between the act of declaring the link, and the moment where a potential fetch actually happens (it doesn't always happen, after all). I agree that stuffing things just to get a fetch to happen earlier maybe a premature optimization. Optimizing prefetch to start before actual document data arrives is highly controversial, but I believe that it's the primary reason why we're considering the Link header implementation. - WBR, Alexey Proskuryakov ___ 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] New mailling list for buildbot events?
Some people have asked for a way to get email from build.webkit.org for build events/results. The simplest and easiest-to-maintain way I think to do this is to make a new mailing list and have the master use that for all buildbot notifications. People can subscribe and use mail filters to get what they really want. Admittedly, that list will get pretty noisy. Does anyone have any better ideas or objections? Thanks, -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New mailling list for buildbot events?
On Thu, Jan 13, 2011 at 5:23 PM, William Siegrist wsiegr...@apple.comwrote: Some people have asked for a way to get email from build.webkit.org for build events/results. The simplest and easiest-to-maintain way I think to do this is to make a new mailing list and have the master use that for all buildbot notifications. People can subscribe and use mail filters to get what they really want. Admittedly, that list will get pretty noisy. Does anyone have any better ideas or objections? What kind of messages will be posted on such a mailing list? - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New mailling list for buildbot events?
On Jan 13, 2011, at 5:41 PM, Ryosuke Niwa wrote: On Thu, Jan 13, 2011 at 5:23 PM, William Siegrist wsiegr...@apple.com wrote: Some people have asked for a way to get email from build.webkit.org for build events/results. The simplest and easiest-to-maintain way I think to do this is to make a new mailing list and have the master use that for all buildbot notifications. People can subscribe and use mail filters to get what they really want. Admittedly, that list will get pretty noisy. Does anyone have any better ideas or objections? What kind of messages will be posted on such a mailing list? It is configurable and the choices are: * all Send mail about all builds, both passing and failing * change Only send mail about builds which change status * failing Only send mail about builds which fail * warning Only send mail about builds which fail or generate warnings * passing Only send mail about builds which succeed * problem Only send mail about a build which failed when the previous build has passed. -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New mailling list for buildbot events?
Interesting. both warning and problem builds sound useful to be able to query via a mailing list archive. :) On Thu, Jan 13, 2011 at 7:21 PM, William Siegrist wsiegr...@apple.com wrote: On Jan 13, 2011, at 5:41 PM, Ryosuke Niwa wrote: On Thu, Jan 13, 2011 at 5:23 PM, William Siegrist wsiegr...@apple.com wrote: Some people have asked for a way to get email from build.webkit.org for build events/results. The simplest and easiest-to-maintain way I think to do this is to make a new mailing list and have the master use that for all buildbot notifications. People can subscribe and use mail filters to get what they really want. Admittedly, that list will get pretty noisy. Does anyone have any better ideas or objections? What kind of messages will be posted on such a mailing list? It is configurable and the choices are: * all Send mail about all builds, both passing and failing * change Only send mail about builds which change status * failing Only send mail about builds which fail * warning Only send mail about builds which fail or generate warnings * passing Only send mail about builds which succeed * problem Only send mail about a build which failed when the previous build has passed. -Bill ___ 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 mailling list for buildbot events?
Getting build bots result for every single revision seems quite noisy. Will be possible to have a page where I can signup for an email or is it too hard to maintain? e.g. If I'm the author of revision X, and I'd like to make sure X passed on all the bots but don't want to waste time by staring at build.webkit.org/for an hour. So being able to go to some page where I can ask email me whenever bots fail for X will be quite useful. - Ryosuke On Thu, Jan 13, 2011 at 7:21 PM, William Siegrist wsiegr...@apple.comwrote: It is configurable and the choices are: * all Send mail about all builds, both passing and failing * change Only send mail about builds which change status * failing Only send mail about builds which fail * warning Only send mail about builds which fail or generate warnings * passing Only send mail about builds which succeed * problem Only send mail about a build which failed when the previous build has passed. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New mailling list for buildbot events?
I'm not sure which category purple bots fall into, but getting notified about those would be useful (e.g. for the Chromium bots that Dimitri, James and I try to keep up). Mihai On Thu, Jan 13, 2011 at 7:29 PM, Eric Seidel e...@webkit.org wrote: Interesting. both warning and problem builds sound useful to be able to query via a mailing list archive. :) On Thu, Jan 13, 2011 at 7:21 PM, William Siegrist wsiegr...@apple.com wrote: On Jan 13, 2011, at 5:41 PM, Ryosuke Niwa wrote: On Thu, Jan 13, 2011 at 5:23 PM, William Siegrist wsiegr...@apple.com wrote: Some people have asked for a way to get email from build.webkit.org for build events/results. The simplest and easiest-to-maintain way I think to do this is to make a new mailing list and have the master use that for all buildbot notifications. People can subscribe and use mail filters to get what they really want. Admittedly, that list will get pretty noisy. Does anyone have any better ideas or objections? What kind of messages will be posted on such a mailing list? It is configurable and the choices are: * all Send mail about all builds, both passing and failing * change Only send mail about builds which change status * failing Only send mail about builds which fail * warning Only send mail about builds which fail or generate warnings * passing Only send mail about builds which succeed * problem Only send mail about a build which failed when the previous build has passed. -Bill ___ 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] Supporting css ime-mode property
On my second thought, it seems like all usage could be addressed by WebKit changing IME status based on lang attribute. e.g. in a page where lang=ja, we'd expect Japanese IME to be enabled and if any input/textarea has lang=en, then we can automatically switch to English IME (e.g. IME is turned off on Windows with Japanese locale). This seems to serve most of the use cases discussed on this thread and avoids introducing platform-dependent concept of IME being off. And it can further be generalized to pages with multiple forms each of which requires input in a different language. - Ryosuke On Tue, Oct 5, 2010 at 5:48 PM, Alexey Proskuryakov a...@webkit.org wrote: On 05.10.2010, at 17:16, Kenichi Ishibashi wrote: Here is another use-case. Some modern CJK web pages provide a way to input Chinese or Japanese text without OS-provided IMEs. You can see an example at http://www.baidu.com/. Click the text next to the search button and select 拼音 or appropriate one, then input text in the search box so you will get the candidate window in a similar way that OS-provided IMEs. When developers want to provide such feature, they might want to control system-level IMEs and the ime-mode property could provide the solution. I think this feature likely to change how people use the Web. I'm not sure if I understand the exact use case. Are you saying that the page will want to suppress OS provided input methods if it does its own? That doesn't seem necessarily useful, and anyway, they don't need ime-mode for this - OS provided input methods won't be invoked if the page returns false from keydown event handler. What I see on baidu.com right now seems much different from an input method though - they are just making a guess at what the user intended to type. Google search works exactly the same, as long as the page language is set appropriately. For Russian, it detects both typing with a wrong keyboard layout (if the user forgot to switch it), and transliteration. For Chinese, it supports at least transliteration. It also detects and corrects typos. All this functionality doesn't seem specific to CJK at all. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] The http tests are very flaky
If you look at the flaky tests reported by the commit queue (since we started tracking about a month ago): https://bugs.webkit.org/show_bug.cgi?id=50856 You see that well over half are http tests. [1] I'm curious if anyone has any theories? These tests are causing a majority of our regular sheriff-bot spam and green/red tree confusion. Maybe something is wrong with Apache on Snow Leopard? Maybe CFNetwork getting stuck? If you click on the individual timeouts, any failures within the last week include failure type information (timeout, text failure, etc.) and any failures within the last few days will have the -diffs.txt file attached. See https://bugs.webkit.org/show_bug.cgi?id=52398 or https://bugs.webkit.org/show_bug.cgi?id=51613 as examples. Looking at the Chromium Flakiness dashboard (which has results going back for months!) we see that many of the same http tests are flaky for chromium too: http://test-results.appspot.com/dashboards/flakiness_dashboard.html I believe they use a different http server (lighttpd, but my information could be old?) and certainly a separate network stack. Solving these flakes would greatly reduce commit-queue delays and noise on build.webkit.org. Thanks. -eric 1. Here is a direct link to all the bugs, you can get this from the master bug by looking at the show dependency tree and then clicking view bugs as list: https://bugs.webkit.org/buglist.cgi?bug_id=51976%2C50855%2C51019%2C51613%2C50958%2C51987%2C51020%2C52164%2C51763%2C51138%2C52117%2C51835%2C52209%2C51102%2C51582%2C51039%2C51558%2C50880%2C51817%2C51594%2C51624%2C29939%2C51913%2C50875%2C52115%2C51314%2C51098%2C51056%2C51733%2C51690%2C51028%2C50995%2C51891%2C51757%2C51649%2C52047%2C52016%2C51009%2C51765%2C51002%2C51130%2C51024%2C52158%2C50959%2C52398%2C52249field-1-0-0=bug_idquery_format=advancedremaction=type-1-0-0=anyexactvalue-1-0-0=51976%2C50855%2C51019%2C51613%2C50958%2C51987%2C51020%2C52164%2C51763%2C51138%2C52117%2C51835%2C52209%2C51102%2C51582%2C51039%2C51558%2C50880%2C51817%2C51594%2C51624%2C29939%2C51913%2C50875%2C52115%2C51314%2C51098%2C51056%2C51733%2C51690%2C51028%2C50995%2C51891%2C51757%2C51649%2C52047%2C52016%2C51009%2C51765%2C51002%2C51130%2C51024%2C52158%2C50959%2C52398%2C52249order=bugs.short_desc%20desc%2Cbugs.bug_idquery_based_on= ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
