1244414 - Intermittent TEST-UNEXPECTED-TIMEOUT | /web-animations/animatable/animate.html | Element.animate() correctly sets the Animation's timeline when triggered on an element in a different document - Test timed out

Status: RESOLVED FIXED

(Testing :: web-platform-tests, defect)

Description

[Phil Ringnalda (:philor)]

https://treeherder.mozilla.org/logviewer.html#?job_id=3201547&repo=mozilla-central

Comment 1

[Brian Birtles (:birtles, Feb 26~ parental leave)]

This is probably because this test assumes the iframe has not loaded yet and waits on its loaded event. It should check its readyState first.

Will look into next week.

Comment 2

[Intermittent Failures Robot]

39 automation job failures were associated with this bug in the last 7 days.

Repository breakdown:
* mozilla-inbound: 26
* fx-team: 10
* mozilla-central: 2
* try: 1

Platform breakdown:
* linux64: 38
* linux32: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1244414&startday=2016-02-08&endday=2016-02-14&tree=all

Comment 3

[Brian Birtles (:birtles, Feb 26~ parental leave)]

Attachment: Don't wait for iframe to load if it has already loaded

Comment 4

[Brian Birtles (:birtles, Feb 26~ parental leave)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=cf5f87aa1c33

Comment 5

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8719680 [details] [diff] [review]
Don't wait for iframe to load if it has already loaded

No, this is racy.  The problem is that iframe.contentDocument will never be null here: it'll either be the initial about:blank document or the data: document.  And in the former case it may well have a readyState of "complete"; at least per spec I think it probably should, if not in our impl.  See https://html.spec.whatwg.org/multipage/browsers.html#creating-a-new-browsing-context step 3 and the fact taht https://html.spec.whatwg.org/multipage/dom.html#current-document-readiness says that this document, not being associated with a parser, should have its current document readiness set to "complete".

The right way to do this in a non-racy way, sadly, is to have your function createElement the iframe, set its src, add the load listener, and then insert it into the document.

Comment 6

[Brian Birtles (:birtles, Feb 26~ parental leave)]

Attachment: Create iframe element from script to avoid racing with the load event

Not sure if we should be using remove() in web-platform-tests, however. It's supported in Edge, but not IE, but I guess that's ok.

Comment 7

[Brian Birtles (:birtles, Feb 26~ parental leave)]

I just re-read your comment---I guess I should add the event listener before attaching to the document.

Comment 8

[Brian Birtles (:birtles, Feb 26~ parental leave)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=33ebd42a2b2a

Comment 9

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8720105 [details] [diff] [review]
Create iframe element from script to avoid racing with the load event

r=me, though doing the appendChild call after the addEventListener would be clearer.  It's probably fine either way, though, because the load event always fires async.

Also, you may want to put back the height/width attrs the iframe used to have...

Comment 10

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/9f1df78b4831

Comment 11

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/9f1df78b4831