Open Bug 1663290 Opened 1 year ago Updated 3 months ago

Consider making afterprint event fire after spinning the event loop

Categories

(Core :: Printing: Setup, task)

task

Tracking

()

People

(Reporter: emilio, Assigned: emilio)

References

Details

(Whiteboard: [print2020])

Attachments

(1 file)

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.

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.

Flags: needinfo?(bugs)
Summary: Make afterprint event fire after spinning the event loop → Consider making afterprint event fire after spinning the event loop
No longer regressed by: 1662996

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.

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.

Flags: needinfo?(bugs)
Whiteboard: [print2020_v83]
Whiteboard: [print2020_v83] → [print2020_v84]
Whiteboard: [print2020_v84] → [print2020_v86]
Duplicate of this bug: 1685011
Whiteboard: [print2020_v86] → [print2020_v88]
Whiteboard: [print2020_v88] → [print2020]
Duplicate of this bug: 1728779

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

You need to log in before you can comment on or make changes to this bug.