afterprint-Event im Firefox zu früh?

[Rolf B]

Hallo alle,

ich habe das in der Antwort auf Timo angesprochen, vielleicht geht es dort unter.

Dieser Code:

window.addEventListener("beforeprint", function() {
   console.log("before print")
});
window.addEventListener("afterprint", function() {
   console.log("after print")
});
window.print()

gibt in Chrome "before print" aus, wartet, bis ich den Print-Dialog schließe, und schreibt dann "after print".

Im Firefox schreibt er "after print" sofort nach "before print" und wartet nicht.

Ist das ein Bug, oder eine zulässige Interpretation von HTML Spec 8.8.2 Printin, printing step 4 (fett von mir):

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.

Rolf

[Der Martin]

Hallo Rolf,

Ist das ein Bug, oder eine zulässige Interpretation von HTML Spec 8.8.2 Printin, printing step 4 (fett von mir):

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.

ich verstehe es so, dass das Verhalten von Firefox zulässig ist. Insbesondere der folgende Satz, den du nicht zitiert hast:

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

Das heißt doch sinngemäß: Die print()-Methode darf sofort zurückkehren, auch wenn der Druckvorgang noch lange nicht abgeschlossen ist. Aber dann muss das gedruckte Dokument exakt dem Zustand zum Zeitpunkt des Methodenaufrufs entsprechen und darf durch nachfolgende DOM-Eingriffe nicht mehr veränderbar sein.

In dem Fall ändert sich die Semantik des afterprint-Events geringfügig: Es sagt dann nicht aus, dass der Druckvorgang physisch beendet ist, sondern nur, dass sozusagen ein Snapshot des Dokuments für den Druck erzeugt wurde.

Live long and pros healthy,
 Martin

[Rolf B]

Hallo Martin,

ja, das lese ich auch so aus diversen Bugzilla-Einträgen. Sie klonen das DOM vollständig, inclusive aller abhängigen Ressourcen. Vor 5 Jahren schrieb jemand "der einzige Grund, warum wir das Navigieren während des Druckens verbieten, sind die Plugins - die sind das einzige was nicht geklont ist".

Die Implikation ist also: Führe nach dem Drucken auf keinen Fall irgendwelche Automatiken durch, die annehmen, dass gedruckt wurde. Denn

• der User kann den Druckdialog abbrechen
• der Druck kann fehlschlagen (keine Tinte, kein Papier, falsches Papier, Papiermarmelade - „Drucker Druckt Nicht“ hat drölftausend Ursachen.

Aber gefallen tut mir das nicht. "afterprint" und "afterpreparedforprinting" sind schon verschiedene Dinge. Die Kontrollmöglichkeiten einer Seite über den Druckablauf sind viel zu gering. Gerade im Unternehmensumfeld ist jeder Klick einer zu viel - die Controller stehen mit der Stoppuhr hinter den Sachbearbeitern und zählen die Mausklicks, die sie machen müssen. Denen zu erklären, dass „die Browser das nicht anders zulassen“, ist so gut wie unmöglich. Dann ändern Sie das doch, heißt es dann. Muahahahahaha.

Rolf