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 pr
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, storag
12.01.2011, в 22:42, Darin Fisher написал(а):
> Supporting the Link header enables web servers to inject 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 behavio
On 13.01.2011 18:02, Alexey Proskuryakov wrote:
12.01.2011, в 22:42, Darin Fisher написал(а):
Supporting the Link header enables web servers to inject tags without
modifying the document, which can be useful, especially for intermediaries.
I'm wondering what the use cases are. To me, addin
Seems reasonable.
On Thu, Jan 13, 2011 at 8:18 AM, Osztrogonac Csaba 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 l
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 exampl
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 p
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.
__
On Thu, Jan 13, 2011 at 8:07 PM, Alexey Proskuryakov 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 [Q
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
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 work
On Thu, Jan 13, 2011 at 9:12 PM, 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 la
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 wrote:
> Seems reasonable.
>
> On Thu, Jan 13, 2011 at 8:18 AM, Osztrogonac Csaba
> wrote:
>>
>> Hi WebKi
2011/1/13 Darin Fisher :
> Supporting the Link header enables web servers to inject 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 hard
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 wrote:
> I would opt for a lower limit, but 500 is certainly better than no limit.
> :)
>
> I would certa
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 wrote:
> There are legit changes that cause hundreds of tests to
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 wrote:
> I mean, we could also have it always stop after 5 crashes, but default
> to 500 for failures or something. Failures (with the
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 i
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 wh
On Thu, Jan 13, 2011 at 5:23 PM, William Siegrist 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 not
On Jan 13, 2011, at 5:41 PM, Ryosuke Niwa wrote:
> On Thu, Jan 13, 2011 at 5:23 PM, William Siegrist 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 l
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 wrote:
>
> On Jan 13, 2011, at 5:41 PM, Ryosuke Niwa wrote:
>
>> On Thu, Jan 13, 2011 at 5:23 PM, William Siegrist
>> wrote:
>> Som
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
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 wrote:
> Interesting. both "warning" and "problem" builds sound useful t
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
turne
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 sher
26 matches
Mail list logo
