1634854 - a few performance-timeline/* tests are expected TIMEOUT

Status: RESOLVED FIXED

(Core :: Performance, defect)

Description

[Joel Maher ( :jmaher ) (UTC -8)]

I am looking into all wpt tests that are expected TIMEOUT. I found a list of them here:
/performance-timeline/buffered-flag-after-timeout.any.js
/performance-timeline/buffered-flag-observer.any.js
/performance-timeline/idlharness.any.js
/performance-timeline/multiple-buffered-flag-observers.any.js
/performance-timeline/po-observe-repeated-type.any.js

I verified locally that these timeout, but I was not able to keep the window open to see if there was any additional information.

I also don't see any bugs easily discoverable related to this. I assume these are features supported in Firefox, this would lead me to start with the tests.

Comment 1

[Joel Maher ( :jmaher ) (UTC -8)]

:jgraham, is there a way to get more information from the test while rerunning it? I assume since these are .any.js files they run multiple tests (any, worker, https, etc.) which the harness treats as a set of tests and not a single test which makes it harder to find more information from the running browser.

Comment 2

[James Graham [:jgraham]]

You can run the actual test e.g. ./mach wpt /performance-timeline/buffered-flag-after-timeout.any.html. I don't think there's a trivial way to know which tests exist other than looking in the .js file and seeing which globals are defined, or looking in the corresponding ini file to see the test names there.

Comment 3

[Joel Maher ( :jmaher ) (UTC -8)]

I am unable to run that:
$ ./mach wpt testing/web-platform/tests/performance-timeline/buffered-flag-after-timeout.any.html
0:00.05 INFO Skipping manifest download because existing file is recent
0:04.19 mozversion INFO application_buildid: 20200417123152
0:04.19 mozversion INFO application_changeset: 263caf99032929230962074227cbb2000430d3b8
0:04.19 mozversion INFO application_display_name: Nightly
0:04.19 mozversion INFO application_id: {ec8030f7-c20a-464f-9b0e-13a3a9e97384}
0:04.19 mozversion INFO application_name: Firefox
0:04.19 mozversion INFO application_remotingname: firefox
0:04.19 mozversion INFO application_vendor: Mozilla
0:04.19 mozversion INFO application_version: 78.0a1
0:04.19 mozversion INFO platform_buildid: 20200417123152
0:04.20 mozversion INFO platform_changeset: 263caf99032929230962074227cbb2000430d3b8
0:04.20 mozversion INFO platform_version: 78.0a1
0:05.13 INFO Using 1 client processes
0:05.13 CRITICAL Unable to find any tests at the path(s):
0:05.13 CRITICAL testing/web-platform/tests/performance-timeline/buffered-flag-after-timeout.any.html
0:05.13 CRITICAL Please check spelling and make sure there are tests in the specified path(s).
0:05.13 INFO Closing logging queue
0:05.13 INFO queue closed

Outside of this, I didn't see anything in the shell output related to errors that might indicate why we have a timeout. :jgraham, is there anything else here we should do before asking the performance team to look into this?

Comment 4

[James Graham [:jgraham]]

Yeah, you need to pass the test id rather than trying to convert it into a path relative to the srdir.

My guess is that the performance observer events aren't being see so the test times out. But better to ask the relevant team than me in this case.

Comment 5

[Joel Maher ( :jmaher ) (UTC -8)]

:plawless, can you help find someone who can look into or comment on the 5 web-platform-tests which are always timing out?

Comment 6

[Sean Feng [:sefeng]]

I am able to reproduce the timeout and I'll take a look.

Comment 7

[Joel Maher ( :jmaher ) (UTC -8)]

thanks :sefeng, let me know if you have any questions

Comment 8

[Sean Feng [:sefeng]]

Attachment: Bug 1634854 - Make performance.observe queues task when buffered is set r=baku

Spec: https://w3c.github.io/performance-timeline/#observe-method

Per sepc, when the buffered flag is set, a PerformanceObserver
task should be queued to notify the observer for buffered entires.

Comment 9

[Sean Feng [:sefeng]]

Joel, can you still reproduce the timeout for /performance-timeline/idlharness.any.js locally? I am unable to reproduce this one.

For the rest, I created a patch to fix it.

Comment 10

[Joel Maher ( :jmaher ) (UTC -8)]

I cannot reproduce any failures or timeouts on /performance-timeline/idlharness.any.js

thanks for checking

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/94da87241e44
Make performance.observe queues task when buffered is set r=baku

Comment 12

[Dorel Luca [:dluca]]

https://hg.mozilla.org/mozilla-central/rev/94da87241e44