User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0

Steps to reproduce:

load this file, containing a script to automatically queue up a print.
Print to a PDF printer utility that uses the "Job Name" as the destination file name.

Actual results:

The created print file is "original title.pdf"

Expected results:

The created print file should be "Never hits the paper.pdf", like it was in 72 branch and 71 branch and probably earlier too.

If it can't be fixed (it is not clear that there is a standard for setting the print job name), hopefully there is new method to set the print job name? But I don't see

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

Further testing indicates that not only document.title is unchanged in this scenario, but any attempt to temporarily alter the document for printing, call window.print(), and then restore the former values to the document for viewing also seems to fail.

I now speculate that window.print() no longer actually prints, or even collects DOM values for printing, but rather "cleverly" queues up an asynchronous event that doesn't get processed until after the restoration code following the call to window.print().

This is a significant, serious, and bug-prone change in behavior.

I can't find a bug by searching window.print or print async that has recent updates that would be an obvious source of this sort of change in behavior, but the change in behavior definitely exists, and definitely alters the printed results from my code, which is trying to make temporary DOM changes for the print process.

Adding an option for making window.print() asynchronous would be OK. Or adding a new API for asynchronous printing would be OK. But changing its default behavior is a breaking change.

Thanks for the bug report. mozregression tells me this was as a result of bug 1602410.

Thanks for tracking this down. After reading the other bug, I tried toggling print.print_via_parent but it made no difference to the test case. I only know what Google found me about IPDL actors, but it talked about messages, and messages are often asynchronous, and I think asynhcronicity is the root cause of this issue. All the information needed for printing should be collected by window.print before it returns. If it chooses to share that information in an asychronous way with the parent (or whoever), that is fine, but it must collect all the information synchronously, because the information is subject to change.

I've verified this bug is in 74 branch also.

If someone can take "1 of 3" out of the title, that would be appropriate. The others had various symptoms, but after analysis, all of the reduced to this problem.

So in my wrapper for window.print(), I make a number of alterations to the document which in 72 branch and earlier, all had an effect on the printed result, but in 73 branch (and current 74 branch) do not have an effect on the result.

1. document.title changed to give the print job a useful name (this is also used by the PDF-capture print driver as the file name)

2. The zoom factor for quality printing. The user has control over the screen zoom factor, but the printed zoom factor wants to be the configured output size.

3. which of several pages the user selected for printing (due to FF inability to print page-crossing iframes, printing has to be done one page at a time. There is a long-standing bug for the printing deficiency: bug 1250348).

4. the addition of bleed area and crop marks, and of margins and gutter (perhaps the user already has these turned on, perhaps not, but they should be included in the print)

All of these items are modified before and restored after the call to window.print() to set up the proper environment for printing, but apparently with the new asynchronous scheme, all of these items are in effect ignored, apparently the examination of the DOM and layout for printing is based on what is seen after the values are restored (since I doubt they were collected beforehand).

Until we get a chance to look into this problem, can you see whether making your modifications in a beforeprint event handler helps?

It's a thought. I only became aware of "beforeprint event handler" and "afterprint event handler" about a week ago, when a co-worker was trying to figure out how to automatic the sequential printing of multiple pages (see point 3 in Comment 9). It was in my thoughts that if Mozilla developers decided to classify this as an "incompatible feature change" that perhaps that stuff might be useful as an alternative.

This might take me some time to figure out, since I've never attempted to use it before, and the current print code is structured synchronously.

Of course, for now the release FF (72 branch) doesn't have the problem, so we are hoping by reporting early that these problems never make it to an official release.

So the beforeprint documentation mentions right off that the use of @media directives is the preferred technique, so I spent a bit of time investigating how the modifications listed in comment 9 are performed.

It seems probable that with some rework of code that items 2, 3, and 4, which are all done by CSS, could be achieved with @media directives. However, the present implementation of these things uses the style attribute as a way to guarantee that the items are changed for printing, as some of the items are also changeable for other reasons, and the cascade could impact the specifics of style rule and style sheet ordering to ensure the right effects, and likewise the selector specificity. Putting items with temporary changes right into the style attribute of elements provided an easy guarantee they would take effect.

However, item 1, the document.title, seems to be unchangeable via CSS, and because it is used for the job name and eventually the file name, it is critical to the process of producing unique file names in the output in an automated fashion. If there is a way to change the content via CSS, let me know. Or if there is a way to specify a print job name different from the document.title, let me know.

So it would seem that beforeprint and afterprint are much more likely to provide a "quick" workaround for this issue, if the bug would be released, and would seem to be the only way to alter document.title, other than wrapping window.print with the DOM change, which works fine in 72 branch and earlier branches.

I'll do some experimenting. Meanwhile, it seems that document.title or print job name might want to acquire a way to be changed via CSS?

(In reply to Glenn Linderman from comment #12)

Meanwhile, it seems that document.title or print job name might want to acquire a way to be changed via CSS?

At some point there will be a way to control the contents of page headers and footers from CSS. PDF formatters all have different ways of supporting this currently. https://drafts.csswg.org/css-gcpm-4/ is a very early draft with some ideas on how to support this.

Thanks, yeah, I'm not holding my breath waiting for that, which I was aware of... so implemented my own 9×9 grid to do prepress pagination with margins, gutter, bleed, and crop marks, and turn off the margins, headers and footers currently defined by Firefox. I suppose to be more general, I should go to 11×11 and include headers and footers also, but didn't need that in this project.

And, BTW, that draft doesn't even mention the idea of print job name, so isn't exactly responsive to the question. But then, I'm not sure what future draft of what spec should mention the idea of a print job name...?

@Glenn: Just in case you missed it, bug 1602410 was backed out of 73 and 74, so hopefully that helps you for now?

Yes, I noticed that, and things have been working, see comment 11.

But I proceeded to put as much as possible into @media print.
@media print doesn't provide a way to set a print job name, so the synchronous call to print, and modifying the title before and after seems to be the only way to achieve that. So if the plan is to go asynchronous, there need to be some adjustments to how data is saved for the asynchronous process, so things continue to work compatibly.

Thanks for reporting this. The backout has now cleared Nightly, Beta and Release.