Bug 148569 – REGRESSION(r188639): [GTK] Several inspector tests started to time out in GTK+ bots after r188639

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Carlos Garcia Campos]

Let's skip them for now

[Carlos Garcia Campos]

Skipped in r189092

[Carlos Alberto Lopez Perez]

*** Bug 148939 has been marked as a duplicate of this bug. ***

[Blaze Burg]

You may need to spend some time getting GTK up to speed with new inspector test infrastructure:

 * Tests load either Test.html or TestStub.html
 * A new method in Internals returns the path to TestStub.html
 * Most tests need to be able to load some auxiliary local files (TestHarness.js, etc) even if they run inside an iframe

[Carlos Garcia Campos]

Created attachment 261926 [details]
Patch

[Carlos Garcia Campos]

(In reply to comment #3)
> You may need to spend some time getting GTK up to speed with new inspector
> test infrastructure:
> 
>  * Tests load either Test.html or TestStub.html
>  * A new method in Internals returns the path to TestStub.html
>  * Most tests need to be able to load some auxiliary local files
> (TestHarness.js, etc) even if they run inside an iframe

This last point was the only thing missing actually. Thanks for your help.

[Blaze Burg]

(In reply to comment #5)
> (In reply to comment #3)
> > You may need to spend some time getting GTK up to speed with new inspector
> > test infrastructure:
> > 
> >  * Tests load either Test.html or TestStub.html
> >  * A new method in Internals returns the path to TestStub.html
> >  * Most tests need to be able to load some auxiliary local files
> > (TestHarness.js, etc) even if they run inside an iframe
> 
> This last point was the only thing missing actually. Thanks for your help.

No problem. Let me know if you have any questions or other issues pop up. I'm hoping to get Windows tests working again soon.

[Carlos Garcia Campos]

Committed r190265: <http://trac.webkit.org/changeset/190265>

[Carlos Garcia Campos]

There are still some tests timing out in the bots, but I think they are just slow. I've tried some of them, for example inspector/css/createStyleSheet.html never times out for me, however inspector/css/stylesheet-events-basic.html fails for me when run with run-webkit-tests and passes when using WTR directly. It also pass when running run-webkit-tests with --no-timeout, the test is a lot slower when using run-webkit-tests for some reason. The thing is that I'm not sure if the slowness is somehow expected or a bug specific to the GTK+ port. It seems to me that the inspector tests actually run multiple test cases per test, so it's probably expected to be slow. Should we mark inspector tests as slow to use a higher timeout?

[Blaze Burg]

(In reply to comment #8)
> There are still some tests timing out in the bots, but I think they are just
> slow. I've tried some of them, for example
> inspector/css/createStyleSheet.html never times out for me, however
> inspector/css/stylesheet-events-basic.html fails for me when run with
> run-webkit-tests and passes when using WTR directly. It also pass when
> running run-webkit-tests with --no-timeout, the test is a lot slower when
> using run-webkit-tests for some reason. The thing is that I'm not sure if
> the slowness is somehow expected or a bug specific to the GTK+ port. It
> seems to me that the inspector tests actually run multiple test cases per
> test, so it's probably expected to be slow. Should we mark inspector tests
> as slow to use a higher timeout?

We have been seeing similar issues for some Mac bots, with tests having high variance and taking several times longer to complete than when running locally, even on very old hardware (2008 MacBook runs tests in ~3s, bots can take up to 40s+). However, I  have not noticed differences between run-webkit-tests and direct WKTR execution. If you are able to find anything out, do file a bug.

<https://webkit.org/b/148636> tracks general flakiness in inspector tests.