Bugzilla

It looks like the failure is intermittent, but the test is reliably slow here even when it doesn't take long enough to time out.

Here are two recent test runs where it passed but still took a long time (~14-17 seconds, whereas neighboring tests took ~500ms):
https://firefoxci.taskcluster-artifacts.net/c_VwMRdgTnKsrfWJfzjm8A/0/public/logs/live_backing.log
> TEST-PASS | /svg/coordinate-systems/viewBox-synthesized-in-img-001.tentative.html | took 16446ms

https://firefoxci.taskcluster-artifacts.net/H7Pj-uqWToCYxUGzwCdh9g/0/public/logs/live_backing.log
> TEST-PASS | /svg/coordinate-systems/viewBox-synthesized-in-img-001.tentative.html | took 14359ms

In the failure quoted in comment 0, the test took 21225ms (21 seconds), so I suspect the timeout threshold on this platform is 20 seconds - so even our "good" test runs are dangerously close to that threshold.

bug 1960779 should reduce some error logging, which might conceivably reduce overhead and test-duration here. If this is still too slow even after that, and it's still mysterious why things are slow, we could conceivably split the test into two pieces (each with a shorter duration), too.

It looks like the failure is intermittent, but the test is reliably slow here even when it doesn't take long enough to time out.

Here are two recent test runs where it passed but still took a long time (~14-17 seconds, whereas neighboring tests took ~500ms):
https://firefoxci.taskcluster-artifacts.net/c_VwMRdgTnKsrfWJfzjm8A/0/public/logs/live_backing.log
> TEST-PASS | /svg/coordinate-systems/viewBox-synthesized-in-img-001.tentative.html | took 16446ms

https://firefoxci.taskcluster-artifacts.net/H7Pj-uqWToCYxUGzwCdh9g/0/public/logs/live_backing.log
> TEST-PASS | /svg/coordinate-systems/viewBox-synthesized-in-img-001.tentative.html | took 14359ms

In the failure quoted in comment 0, the test took 21225ms (21 seconds), so I suspect the timeout threshold on this platform is 20 seconds - so even our "good" test runs are dangerously close to that threshold (i.e. the 14-17s "good" durations are quite close to 20s).

bug 1960779 should reduce some error logging, which might conceivably reduce overhead and test-duration here. If this is still too slow even after that, and it's still mysterious why things are slow, we could conceivably split the test into two pieces (each with a shorter duration), too.