Bug 99632 – [chromium] Re-enable gesture highlight layout tests, fix GestureLongPress regression.

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[W. James MacLean]

[chromium] Re-enable gesture highlight layout tests, fix GestureLongPress regression.

[W. James MacLean]

Created attachment 169248 [details]
Patch

[W. James MacLean]

Comment on attachment 169248 [details]
Patch

Just realized the new baselines are wrong due to the Precise fonts being different ... will revise patch and re-upload.

[W. James MacLean]

Created attachment 169472 [details]
Patch

[WebKit Review Bot]

Comment on attachment 169472 [details]
Patch

Clearing flags on attachment: 169472

Committed r131823: <http://trac.webkit.org/changeset/131823>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[Adam Barth]

This patch did not appear to fix https://bugs.webkit.org/show_bug.cgi?id=96951 despite removing the lines in TestExpectations that reference that bug.

[W. James MacLean]

(In reply to comment #6)
> This patch did not appear to fix https://bugs.webkit.org/show_bug.cgi?id=96951 despite removing the lines in TestExpectations that reference that bug.

I don't quite follow. Are you saying the chromium-linux link highlight tests aren't being run on the bots? They do run locally on my linux machine via new-run-webkit-tests.

[Adam Barth]

> I don't quite follow. Are you saying the chromium-linux link highlight tests aren't being run on the bots? They do run locally on my linux machine via new-run-webkit-tests.

You unskipped the tests without fixing Bug 96951.  I noticed that Bug 96951 was occurring again, and I skipped the tests again.  Please do not re-enable these tests without fixing Bug 96951.  It slows down the entire project.

[W. James MacLean]

(In reply to comment #8)
> > I don't quite follow. Are you saying the chromium-linux link highlight tests aren't being run on the bots? They do run locally on my linux machine via new-run-webkit-tests.
> 
> You unskipped the tests without fixing Bug 96951.  I noticed that Bug 96951 was occurring again, and I skipped the tests again.  Please do not re-enable these tests without fixing Bug 96951.  It slows down the entire project.

Based on our investigation the flakiness was not limited to (nor caused by) the gesture highlight tests.

It appears to be some state the compositor gets into, and seemingly on another (possibly passing) test. I'm going to guess there are still other compositor tests failing in the same way, as this was the pattern before.

If that's the case, then by your logic above we should be disabling all the compositor tests that exhibit flake. Are other compositor tests failing?

[Adam Barth]

Here's what I know:

1) If we run these tests, we get large queuing delays in the EWS.
2) If we skip these tests, we do not get large queuing delays.
3) Large queuing delays are not acceptable.

I'd love to enable these tests, but we cannot enable them if they cause large queuing delays.  It might well be that the problem is with the compositor and affects other tests, but that doesn't mean that we can enable the tests.

[W. James MacLean]

(In reply to comment #10)
> Here's what I know:
> 
> 1) If we run these tests, we get large queuing delays in the EWS.
> 2) If we skip these tests, we do not get large queuing delays.
> 3) Large queuing delays are not acceptable.
> 
> I'd love to enable these tests, but we cannot enable them if they cause large queuing delays.  It might well be that the problem is with the compositor and affects other tests, but that doesn't mean that we can enable the tests.

Fair enough, but now we have *zero* test coverage on this feature.

Perhaps it would have been better to see if there was some critical subset of these tests that might stay on, while we disable the rest, so we can have the best of both worlds?

Perhaps if we need this many tests turned off, the load can be distributed so that it's not just highlight tests being turned off.

[Adam Barth]

I sympathize, but I'd rather we just fixed the underlying problem.  These tests have caused this problem since they were introduced.

[W. James MacLean]

(In reply to comment #12)
> I sympathize, but I'd rather we just fixed the underlying problem.  These tests have caused this problem since they were introduced.

I'd rather we fixed the underlying problem too, and while I had some resources available I was attempting to do so. But I no longer have anyone to work on the problem, myself included.