On Wed, Oct 31, 2012 at 12:05 AM, Alexey Proskuryakov a...@apple.com wrote:
This will mean that cache is always almost empty, and all resources in it
are extremely fresh. I don't know if this would provide substantial
additional test coverage over cleaning the cache all the time, or just
On Fri, Nov 2, 2012 at 12:33 PM, Antti Koivisto koivi...@iki.fi wrote:
On Wed, Oct 31, 2012 at 12:05 AM, Alexey Proskuryakov a...@apple.comwrote:
This will mean that cache is always almost empty, and all resources in it
are extremely fresh. I don't know if this would provide substantial
On Oct 28, 2012, at 3:30 PM, Antti Koivisto koivi...@iki.fi wrote:
We could clear the cache between tests but run each test twice in a row.
Second run will then happen with deterministically pre-populated cache. That
would both make things more predictable and improve our test coverage for
On Mon, Oct 29, 2012 at 5:48 AM, Maciej Stachowiak m...@apple.com wrote:
On Oct 28, 2012, at 10:09 PM, Dirk Pranke dpra...@chromium.org wrote:
On Sun, Oct 28, 2012 at 6:32 AM, Maciej Stachowiak m...@apple.com wrote:
I think the nature of loader and cache code is that it's very hard to make
On Oct 26, 2012, at 11:11 PM, Ryosuke Niwa rn...@webkit.org wrote:
I’m sure Antti, Alexey, and others who have worked on the loader and other
parts of WebKit are happy to write those tests or list the kind of things
they want to test. Heck, I don’t mind writing those tests if someone
We could clear the cache between tests but run each test twice in a row.
Second run will then happen with deterministically pre-populated cache.
That would both make things more predictable and improve our test coverage
for cached cases. Unfortunately it would also slow down testing
significantly,
We can live in one of two worlds:
1) LayoutTests that concern themselves with specific network/loading
concerns need to use unique URLs to refer to static data; or
2) DRT clears JS-visible state between tests.
The pros/cons seem clear to me:
Pro#1: loading/caching code is coincidentally
On Oct 26, 2012, at 11:11 PM, Ryosuke Niwa rn...@webkit.org wrote:
I’m sure Antti, Alexey, and others who have worked on the loader and other
parts of WebKit are happy to write those tests or list the kind of things
they want to test. Heck, I don’t mind writing those tests if someone could
On 10/28/2012 08:25 PM, Ami Fischman wrote:
We can live in one of two worlds:
1) LayoutTests that concern themselves with specific
network/loading concerns need to use unique URLs to refer to
static data; or
2) DRT clears JS-visible state between tests.
The pros/cons
On Sun, Oct 28, 2012 at 2:47 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Sun, Oct 28, 2012 at 2:09 PM, Dirk Pranke dpra...@chromium.org wrote:
On Oct 26, 2012, at 11:11 PM, Ryosuke Niwa rn...@webkit.org wrote:
I’m sure Antti, Alexey, and others who have worked on the loader and
other parts
On Sun, Oct 28, 2012 at 4:37 PM, Dirk Pranke dpra...@chromium.org wrote:
On Sun, Oct 28, 2012 at 2:47 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Sun, Oct 28, 2012 at 2:09 PM, Dirk Pranke dpra...@chromium.org
wrote:
On Oct 26, 2012, at 11:11 PM, Ryosuke Niwa rn...@webkit.org wrote:
There are lot of things remaining in the process across tests runs
What things remain in the process across test runs that are visible to
DRT/JS?
As I've said before in this thread, it seems axiomatic to me that tests can
only be reasoned about if they run in a pristine environment. This is
27.10.2012, в 20:47, Ami Fischman fisch...@chromium.org написал(а):
There are lot of things remaining in the process across tests runs
What things remain in the process across test runs that are visible to
DRT/JS?
Memory allocator state. Computer's real time clock. Hard drive's head
This thread stalled out because although there seemed to be majority
agreement that hermetic/repeatable tests are a good thing, there was a
requirement that all ports be updated to the new behavior at the same time,
and I'm only competent to do the chromium DRT (see
On Wed, Aug 8, 2012 at 9:54 PM, Eric U er...@google.com wrote:
On Wed, Aug 8, 2012 at 11:43 AM, Alexey Proskuryakov a...@webkit.org
wrote:
I can see some downsides to emptying the cache before each test:
- we won't be getting any test coverage for cache behavior when it hits
non-trivial
On Fri, Oct 26, 2012 at 1:44 AM, Antti Koivisto koivi...@iki.fi wrote:
Cache has subtle interactions with other things being tested
(-flakiness). More explicit cache tests would be nice but we can't hope
the replicate all the accidental testing we now get. We are going to lose a
large chunk
I don't know that there was consensus that every port had to be
updated at the same time; in fact Balazs said Qt and EFL already clear
the cache.
I think you should just land the change for Chromium and let others
update their ports as needed. The value in reduced flakiness and more
On Fri, Oct 26, 2012 at 6:09 PM, Ami Fischman fisch...@chromium.org wrote:
The reality is that this test coverage today shows up as flakiness and
so is ignored anyway, meaning we don't actually have useful coverage here.
Even when flakiness is investigated, the fix is to cache-bust using
On Fri, Oct 26, 2012 at 11:17 AM, Ryosuke Niwa rn...@webkit.org wrote:
...
I agree this is a good change but it appears that we should add more
cache/loader tests before changing DRT's behavior given that there are
active contributors who rely on the current DRT behaviors to detect
On Fri, Oct 26, 2012 at 11:33 AM, Elliott Sprehn espr...@chromium.orgwrote:
On Fri, Oct 26, 2012 at 11:17 AM, Ryosuke Niwa rn...@webkit.org wrote:
...
I agree this is a good change but it appears that we should add more
cache/loader tests before changing DRT's behavior given that there
On Fri, Oct 26, 2012 at 11:38 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Fri, Oct 26, 2012 at 11:33 AM, Elliott Sprehn espr...@chromium.org
wrote:
On Fri, Oct 26, 2012 at 11:17 AM, Ryosuke Niwa rn...@webkit.org wrote:
...
I agree this is a good change but it appears that we should add
On Fri, Oct 26, 2012 at 11:17 AM, Ryosuke Niwa rn...@webkit.org wrote:
I agree this is a good change but it appears that we should add more
cache/loader tests before changing DRT's behavior given that there are
active contributors who rely on the current DRT behaviors to detect
regressions.
26.10.2012, в 11:04, Antti Koivisto koivi...@iki.fi написал(а):
The reality is that this test coverage today shows up as flakiness and so
is ignored anyway, meaning we don't actually have useful coverage here. Even
when flakiness is investigated, the fix is to cache-bust using unique URL
Should we add random sleeps to DRT? It'll certainly help find some
regressions (and even security bugs).
Of course the down-side is that it makes tests non-repeatable and difficult
to reason about.
I'm baffled by your priorities and don't know how to continue this
conversation productively.
On Fri, Oct 26, 2012 at 11:43 AM, Dirk Pranke dpra...@chromium.org wrote:
On Fri, Oct 26, 2012 at 11:38 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Fri, Oct 26, 2012 at 11:33 AM, Elliott Sprehn espr...@chromium.org
wrote:
On Fri, Oct 26, 2012 at 11:17 AM, Ryosuke Niwa rn...@webkit.org
On Fri, Oct 26, 2012 at 2:11 PM, Ryosuke Niwa rn...@webkit.org wrote:
Is there any reason we can’t wait for another couple of weeks or months
until we add more loader cache tests before making the behavior change?
There is no time pressure here other than a desire to avoid this falling
26.10.2012, в 14:57, Dirk Pranke dpra...@chromium.org написал(а):
Perhaps a slight variant of this is that we can agree to make the
changes on the Chromium port to clear the cache (much like the Qt and
EFL ports already do), and you can continue to not clear the cache on
the Apple Mac port
Actually Qt and EFL DRT's already does that.
On 08/08/2012 07:47 PM, Ojan Vafai wrote:
See https://bugs.webkit.org/show_bug.cgi?id=93195.
media/W3C/video/networkState/networkState_during_progress.html
and media/video-poster-blocked-by-willsendrequest.html are flaky on
all platforms because
See https://bugs.webkit.org/show_bug.cgi?id=93195.
media/W3C/video/networkState/networkState_during_progress.html
and media/video-poster-blocked-by-willsendrequest.html are flaky on all
platforms because they behave differently if the loaded resource is cached.
Every time I've taken a stab at
That sounds like a great idea to me. I was actually surprised when fischman
told me we don't currently do this.
- Ryosuke
On Wed, Aug 8, 2012 at 10:47 AM, Ojan Vafai o...@chromium.org wrote:
See https://bugs.webkit.org/show_bug.cgi?id=93195.
I can see some downsides to emptying the cache before each test:
- we won't be getting any test coverage for cache behavior when it hits
non-trivial size;
- this may well make tests measurably slower;
- this will be yet another cause of subtle difference between platforms, as
some will
On Wed, Aug 8, 2012 at 11:43 AM, Alexey Proskuryakov a...@webkit.org wrote:
I can see some downsides to emptying the cache before each test:
- we won't be getting any test coverage for cache behavior when it hits
non-trivial size;
Then let's add a cache test explicitly for this. Otherwise we
On Wed, Aug 8, 2012 at 11:43 AM, Alexey Proskuryakov a...@webkit.org wrote:
I can see some downsides to emptying the cache before each test:
- we won't be getting any test coverage for cache behavior when it hits
non-trivial size;
We should have a separate test for that as Eric pointed
On Wed, Aug 8, 2012 at 10:47 AM, Ojan Vafai o...@chromium.org wrote:
See https://bugs.webkit.org/show_bug.cgi?id=93195.
media/W3C/video/networkState/networkState_during_progress.html and
media/video-poster-blocked-by-willsendrequest.html are flaky on all
platforms because they behave
34 matches
Mail list logo
