1685011 - Event afterprint fires early

Status: RESOLVED DUPLICATE of bug 1663290

(Core :: Printing: Setup, defect)

Description

[Robin Miller]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0

Steps to reproduce:

Firefox triggers the afterprint event when the print dialog is opened, not after printing has actually occurred, contrary to spec.

Reproduce with:
window.onbeforeprint = function () {
console.log('before') // this should appear when the dialog appears
};
window.onafterprint = function () {
console.log('after') // this should appear when the dialog disappears, but actually appears immediately
};
window.print();

Actual results:

The event afterprint is fired prior to printing the file or closing the dialog.

Expected results:

The event afterprint should be fired after the file is actually printed or the dialog is closed.

The Living Standard describes afterprint as "Fired at the Window after printing":
https://html.spec.whatwg.org/multipage/indices.html#event-afterprint

MDN docs describe it:
"The afterprint event is fired after the associated document has started printing or the print preview has been closed."
https://developer.mozilla.org/en-US/docs/Web/API/Window/afterprint_event

For comparison, Chrome fires afterprint after the dialog is closed in either case (printing dispatched or dialog cancelled).

Comment 1

[Robin Miller]

Attachment: afterprint-test.html

Comment 2

[Robin Miller]

Just noting that I discovered this via the snippet "Print an external page without opening it" from this guide:
https://developer.mozilla.org/en-US/docs/Web/Guide/Printing#Print_an_external_page_without_opening_it

Running it produces an error dialog titled "Print Preview Error", and message "An error occurred while printing".

I think the snippet breaks because afterprint is fired immediately, which removes the iframe being printed.

The printing routine appears to become very grumpy about printing something that does not exist.

Possibly related to the work done around bug #1557983

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 4

[Raluca Popovici, Desktop QA]

I am assigning a component to this issue in order to involve the development team and get an opinion on this. If is not the correct component please feel free to change it to an appropriate one.

Comment 5

[Emilio Cobos Álvarez (:emilio)]

Given how printing works in Firefox (we create a clone of the document and print that), we have no need to wait until printing is actually done to fire it. All the changes done in the afterprint event shouldn't be reflected in the printed output.

Is this causing some correctness issue? Or something else? We have bug 1663290 on file to track changing this, see the comments there about the trade-offs.

Note also that the printing process itself can take quite a long time on some machines or long documents (if you print a 100 pages document to a printer with a slow driver for example). The current setup allows the user to keep using Firefox while we're actually printing.

Comment 6

[Robin Miller]

I think it's a correctness issue? All I can say for sure is that the code from the MDN guide that worked before breaks now, which strikes me as a regression. Calling window.print() inside iframes removed by the parent's afterprint throws a generic "An error occurred while printing" error. It's sort of similar to the sequencing in bug 1662975.

Looking at the WHATWG - Printing Steps, Step 4: (emphasis mine)

The user agent should offer the user the opportunity to obtain a physical form (or the representation of a physical form) of the document. The user agent may wait for the user to either accept or decline before returning; if so, the user agent must pause while the method is waiting. [...]

The previous Firefox behaviour was to block but now does not. I think it's compliant either way, so the bug cause listed here is probably wrong. For what it's worth, WHATWG has a github issue and PR from 2019 that also expect the blocking behaviour.

But continuing Step 4:

[...] Even if the user agent doesn't wait at this point, the user agent must use the state of the relevant documents as they are at this point in the algorithm if and when it eventually creates the alternate form.

Maybe the real bug is that removing the iframe drops its document while the print routine is using it? Totally guessing at this point.

If it's better, I can make a new bug or add to 1663290 a note and this test file.

Comment 7

[Emilio Cobos Álvarez (:emilio)]

(In reply to Robin Miller from comment #6)

Maybe the real bug is that removing the iframe drops its document while the print routine is using it? Totally guessing at this point.

If it's better, I can make a new bug or add to 1663290 a note and this test file.

Ah, yeah, please file a new bug with that test-case and I'm happy to take a look. That's not supposed to happen... Thanks!

Comment 8

[Jonathan Watt [:jwatt]]

Robin, are you able to file that bug? :-)

Comment 9

[Robin Miller]

Oh, yes, sorry. Got busy and this dropped off my radar. Will post it this week.

Thanks for the reminder.

Comment 10

[Robin Miller]

Final update: just got the the time to put a new bug together but looks like this was fixed in Firefox 85 or 86 because the test cases are now working happily.

Hooray! (and thanks all)