(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)
And to reinstate the previous discussion on matrix here, for posterity, the tricky thing is that there are two kinda-competing use cases here:
- Making it fire as we do now means that the users can't observe the "in-between-beforeprint-and-afterprint" state now while the dialog is open, which is nice.
- Making it fire later means that authors have a bit more flexibility on the kind of stuff they can do with the event.
If you fire it earlier you create discrepancies between both the current documentation and other browsers like Chrome, it would be unsettling for developers. It seems to me that we are using 2 events to describe N operations:
- opening the print dialog
- cloning the document
- closing the print dialog
(I might get them wrong because the internals are not clear to me but you get the point)
From the user standpoint, I'd rather opt for a predictible and standard behaviour, be it imperfect. "afterprint" means what it means, from the name I'd expect it to fire after the print is done/cancelled.