1663290 - Consider making afterprint event fire after spinning the event loop

Status: NEW

(Core :: Printing: Setup, task)

Description

[Emilio Cobos Álvarez (:emilio)]

It makes sense to do stuff like window.print() and call window.close() on an afterprint event listener. This also matches the behavior from before bug 1557983.

Comment 1

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1663290 - Make afterprint fire after spinning the event loop during window.print().

Closing the window after print makes sense.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

So I wrote the patch for this and after writing the test I realized this couldn't ever have worked, because of the IsInModalState() check here.

I uploaded the patch regardless... though I'm not sure it's quite worth landing right now giving all the already-somewhat-significant behavior changes.

Olli do you have thoughts? You suggested this change to make onafterprint = () => window.close() work, so it's really your call.

Comment 3

[Emilio Cobos Álvarez (:emilio)]

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.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

I was thinking the same issue still last night.
One option to fix window.close() case would be to have a flag that one tried to close a window when
modal dialog was open, and then when modal state is removed, the window would be closed. That wouldn't be printing specific tweak.
And then afterprint could call window.close() successfully. And yet user would see less weird page in the background of the print preview.

Comment 7

[eb]

(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
• applying @media print, which is by the way impossible to detect in Firefox, which makes it then difficult to trigger JavaScript based resizing after the media is switched to print and the CSS has been applied.

(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.

Comment 9

[nabrown78]

I am trying to modify the document title on beforeprint (so that a saved PDF name has a certain format) and set it back to its original state on afterprint. Because Firefox fires the afterprint event immediately, this doesn't work. I don't know the browser implementation details, but as a web app developer I think afterprint should be fired once the print dialog is closed, either on Cancel or successful print.

Comment 10

[Woody Li]

Another question: print some area in page by open a temporary page and set content in it.
Open a new page by var win=window.open().
Then print the page by win.print().

It throws an error: win.print is undefined.
Only reproduces in Android Firefox and works well in desktop version.