This is from a Chromium bug report:
https://code.google.com/p/chromium/issues/detail?id=364442

It was fixed by ignoring the loop attribute part of the definition in the context of play():
https://codereview.chromium.org/898883003/

For a spec fix, it probably makes more sense to separate out "The current playback position is the end of the media resource, and the direction of playback is forwards" into a separate definition and using that in play().

I'm confused. What behaviour are you expecting if a loop attribute is added when the media element is paused after having ended playback?

The expectation is that if the "ended playback" predicate is true, adding the loop attribute does not cause it to become false, as the actual state of playback did not change. Calling play() should then seek to the earlier possible position just as it would if the loop attribute was not present.

(The expectation is not that playback should continue at the time the loop attribute is added or anything like that.)

Looking at this a second time, I think the most natural fix could be to remove "Either the media element does not have a loop attribute specified, or the media element has a current media controller" from the definition of "ended playback" and add those conditions to the call sites where they are needed. play() already does the right thing here it seems, I haven't look closely at the other cases.

If play() does what you want, I'm not really sure I understand what doesn't do what you want. Sorry if I'm being dumb here...

Well no, play() doesn't do what I want, because the addition of the loop attribute causes <https://html.spec.whatwg.org/#ended-playback> to go from true to false, which changes the behavior of <https://html.spec.whatwg.org/#dom-media-play>.

The current spec seems to assume that one cannot be paused at currentTime==duration with the loop attribute present, but all one needs to do is to add the loop attribute after reaching currentTime==duration.

I see what you're saying. How about adding this text to just before the note that says "The word "reaches" here does not imply that...":

When a _loop_ content attribute is added to a _media element_ that does not have a _current media controller_ but whose _current playback position_ has reached the end of the _media resource_ and whose _direction of playback_ is forwards, the user agent must _seek_ to the _earliest possible position_ of the _media resource_.

That would allow the subsequent play() to actually play, but I think it's a bit odd to seek (but not play) in response to adding the loop attribute. In particular if there's a "Loop" option in the context menu, it would be surprising if merely toggling that would also cause a seek.

How about the suggestion at the end of comment #4, does that have any drawbacks that you can see?

It just seems like a brittle fix (e.g. we have to go through all those call sites and understand for each one what the implications are, possibly going to their call sites, etc).

A more local fix would be to change step 2 of play() from

"If the playback has ended and the direction of playback is forwards, and the media element does not have a current media controller, seek to the earliest possible position of the media resource."

to

"If the current playback position is the end of the media resource and the direction of playback is forwards, and the media element does not have a current media controller, seek to the earliest possible position of the media resource."

The definition of the ended attribute should probably also change in that case.

(I would slightly prefer to change the definition of ended playback itself and fix up all the call sites, but that amounts to an editorial decision.)

https://github.com/whatwg/html/issues/4487