<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><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">161242</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>[GTK][Threaded Compositor] Several flaky tests
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr>
<tr>
<th>Product</th>
<td>WebKit
</td>
</tr>
<tr>
<th>Version</th>
<td>WebKit Local Build
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Unspecified
</td>
</tr>
<tr>
<th>OS</th>
<td>Unspecified
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Keywords</th>
<td>Gtk
</td>
</tr>
<tr>
<th>Severity</th>
<td>Normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P2
</td>
</tr>
<tr>
<th>Component</th>
<td>Tools / Tests
</td>
</tr>
<tr>
<th>Assignee</th>
<td>webkit-unassigned@lists.webkit.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>cgarcia@igalia.com
</td>
</tr>
<tr>
<th>CC</th>
<td>bugs-noreply@webkitgtk.org, clopez@igalia.com, lforschler@apple.com
</td>
</tr></table>
<p>
<div>
<pre>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.</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>