[Affected versions]: - Beta 53.0b8 - Developer Edition 54.0a2 - Nightly 55.0a1 [Affected Platforms] - All Windows [Prerequisites]: -Create a new clean Firefox profile. [Steps to reproduce]: 1. Navigate to www.bostonglobe.com. (Timing is key on the next 5 steps) 2. Hold "Ctrl" key and click the refresh button (which should load in new tab). 3. Before the page is fully loaded, oress "Ctrl-P" (print window won't appear as page is loading). 4. Quickly dismiss the "Cannot print this document yet, it is still being loaded" dialog. 5. Switch to original tab and quickly press "Ctrl-P" (print window should appear immediately). 6. Wait for second print window to appear (when the second tab finishes loading). 7. Move second window, so you can see both print windows. 8. Click "Cancel" on first window. 9. Press "Ctrl-P" (which should give two dialogs saying printing is not available. 10. Click "Cancel" button on second "Print" window. 11. Click "OK" on both messages dialogs. 12. Press "Ctrl-P" (print window should appear immediately). 13. Click "OK" button in order to print the page. 14. Observe the browser behavior. [Expected Results]: - A printing process is displayed, then the printer starts and the page is correctly printed. [Actual Results]: - A printing process is displayed, but then you get the "An error occurred while printing" dialog. As soon as this happens, the printer starts, but only a blank page is printed. [Regression]: Last good revision: ddc9b2697068639ae1980c6753f79578301eedf6 First bad revision: a4b0052954d201710b37d39fb4e583254382086b Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ddc9b2697068639ae1980c6753f79578301eedf6&tochange=a4b0052954d201710b37d39fb4e583254382086b Looks like the following bug has the changes which introduced the regression: https://bugzilla.mozilla.org/show_bug.cgi?id=1279699 [Notes]: - The same behavior can be observed even if you open a new tab and try to print the page. - The issue is also reproducible if you try to print the page to PDF. - The print functionality will work again only if the browser is restarted. - I have manged to reproduce thie issue on Windows 7 x64 and Windows 10 X64. - Here is a screen recording with the issue: https://goo.gl/ofxhIw. - Here is a browser console error: https://goo.gl/Na1wSK

Thanks for filing. I can't reproduce this at the moment. Would you set the following environment variables before starting firefox and then reproduce the issue please: MOZ_LOG=printing:5,printing-widget:5,sync MOZ_LOG_FILE=%TEMP%\bug1352383printing.log You might have to add quotes and/or escape the "\" depending on how you set them. Can you then attached the log file, thanks, there might be a clue to where it's failing.

I am not sure if I'm doing this right. First I have crate a ".bat" file with the following lines: set MOZ_LOG=printing:5,printing-widget:5,sync set MOZ_LOG_FILE=C:\Users\cosmin.muntean\Desktop\Logs\bug1352383printing.txt "C:\Program Files\Nightly\firefox.exe" -no-remote -p Then I have run the ".bat" file, the browser started and I reproduce the issue. Here are the files created in the "Log" folder: https://goo.gl/Zd0ipO Please let me know if I am doing something wrong. I think the issue is only reproducible on new Firefox profiles. I haven't managed to reproduce it on older profiles.

(In reply to Cosmin Muntean [:CosminMCG] from comment #2) > I am not sure if I'm doing this right. First I have crate a ".bat" file with > the following lines: > set MOZ_LOG=printing:5,printing-widget:5,sync > set MOZ_LOG_FILE=C:\Users\cosmin.muntean\Desktop\Logs\bug1352383printing.txt > "C:\Program Files\Nightly\firefox.exe" -no-remote -p > > Then I have run the ".bat" file, the browser started and I reproduce the > issue. Here are the files created in the "Log" folder: https://goo.gl/Zd0ipO > Please let me know if I am doing something wrong. > > > I think the issue is only reproducible on new Firefox profiles. I haven't > managed to reproduce it on older profiles. Ah, yes, I can reproduce on a just created profile and you don't even have to do any of the dance in the STR. It's because the parent isn't setting up the content temp directory properly and so is looking in the wrong place for the print recording file. I suspect this is the problem with bug 1329294 as well.

Fix for bug 1329294 was just pushed...

Bob, can we close this out or do we have follow up work to do here?

(In reply to Jim Mathies [:jimm] from comment #5) > Bob, can we close this out or do we have follow up work to do here? Bug 1329294 is uplifted now, so this is fixed.