So, is this a "onsubmit" like in the browser? Or logically a "submit success"? I.e. do we wait for submit to finish?

browser not success. So this would happen regardless of the result of the submission but not when the submission doesn't actually happen (client-side validation errors would not trigger a submit event) .

Ok. In that case, we should just add "submit" even right away, right where we add this.addEvent('tap');. Any reason not to do it there?

I just figured no reason to listen to that event if the users do haven't included the amp-form. But I guess we're already kinda doing that with document-submit so might as well add it for the events right away.

I was also worried about the sequence in which events handlers will be called, my understanding if the other ones are capture they should be called first, no?

Correct. Although needed to be tested. You can also call actionService.trigger() from your existing global submit handler. Or even from both: global and the one in the AmpForm. As long as one even is always sent and no more than one. But I'd generally gravitate toward the global handlers, either via addEvent or global submit handler.

Done.

Well, it depends on registration order. With this registered in capture phase, and the action registered in bubble phase, it doesn't though.

Not entirely sure if I understand but even with capture, how would you stop the event from propagating to the listener in actions-impl?

It seems for tap event we're using e.defaultPrevented to prevent triggering in actions. But we can't use this with submit event because we always preventDefault when we do xhr submission, so we can't use that signal to prevent action from triggering.

For the XHR it might actually make sense to set a property on the event.

However, what I meant is that when stopImmediatePropagation is important over stopPropagation you need to be super careful about order. But the way you currently set up handlers registration order does not make a difference.