<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - [GTK][Threaded Compositor] Several flaky tests"
href="https://bugs.webkit.org/show_bug.cgi?id=161242#c3">Comment # 3</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - [GTK][Threaded Compositor] Several flaky tests"
href="https://bugs.webkit.org/show_bug.cgi?id=161242">bug 161242</a>
from <span class="vcard"><a class="email" href="mailto:cgarcia@igalia.com" title="Carlos Garcia Campos <cgarcia@igalia.com>"> <span class="fn">Carlos Garcia Campos</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=161242#c2">comment #2</a>)
<span class="quote">> (In reply to <a href="show_bug.cgi?id=161242#c0">comment #0</a>)
> > Even after fixing <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - [GTK][Threaded Compositor] Several flaky tests due to differences in scrollbars"
href="show_bug.cgi?id=160450">bug #160450</a> we still have a lot of laky tests sometimes in
> > the bots. We no longer see the problem of scrollbars partially rendered, but
> > we see scrollbars in some cases where they shouldn't be there at all (the
> > contents are not bigger than the view size). That made me think that maybe
> > there are tests leaving the view in an inconsistent state, most of the flaky
> > tests are ref tests and all run by the same worker. But I tried to run all
> > the tests using a single worker and I couldn't reproduce the problem so
> > there must be something else. The other thing I can think of is that maybe
> > in some cases the bot is more overloaded and a particular worker has less
> > priority and things happen slower. We are still assuming that scheduling the
> > task in the next loop iteration in the UI process after a force redraw
> > ensures a redraw. The patch I initially posted in <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - [GTK][Threaded Compositor] Several flaky tests due to differences in scrollbars"
href="show_bug.cgi?id=160450">bug #160450</a> as a
> > workaround tried to fix that assumption. I'm not sure that's the problem
> > though, but we could try that patch and roll it out if it doesn't work. I'm
> > a bit lost with this, because it only happens sometimes in the bots and I've
> > never been able to reproduce it locally in any of machines I've tried.
>
> I think you will be able to reproduce this if you run the whole test suite
> instead a subset of it.</span >
I did run all the tests using a single worker.
<span class="quote">> And this is something that I believe was happening before the threaded
> compositor with other kind of tests.
>
> I have found many tests that are flaky when the whole test suite is run, but
> if you run then manually or you run a subset of the test suite (for example:
> run only the fast/ tests). Then its not longer reproducible.
>
> I'm not sure if the problem is on webkit itself or is in the tooling and the
> way the tests are ran.</span >
I'm pretty sure the problem is in the tests infrastructure.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>