Closed Bug 1236015 Opened 4 years ago Closed 3 years ago
File menu>Print>Microsoft Print to PDF always results in ERROR
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; Touch; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729; Tablet PC 2.0; MASEJS; rv:11.0) like Gecko Steps to reproduce: File menu>Print>Microsoft Print to PDF Actual results: Error message Expected results: Make the PDF file
WFM on Fx44b4 Win10.
Component: Untriaged → Printing: Output
Product: Firefox → Core
Does not work for me with e10s enabled on 01/06/2016 nightly ( Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0).
Probably this is a known issue. Workaround suggested by Alice in Bug 1189846 is to set security.sandbox.content.level = 0 in about:config
Setting 'print.print_via_parent' to true in about:config also works for me (and it's probably safer than setting the sandbox pref).
print.print_via_parent is already true (default) but still there's an error when print to PDF is attempted with e10s is enabled. Only security.sandbox.content.level = 0 fixes it.
Hi both. Assuming that you were both trying this in Nightly, can you both retest with the latest Nightly. Thanks.
Problem still seen on Nightly (BuildID:20160202030232) with e10s enabled, print.print_via_parent = true, security.sandbox.content.level=2
Looks like something is broken. I am always getting an error irrespective of the settings.
(In reply to ced from comment #8) > Looks like something is broken. I am always getting an error irrespective of > the settings. Thanks for testing this, can you print with Firefox Release or a different application?
(In reply to Bob Owen (:bobowen) from comment #9) > (In reply to ced from comment #8) > > Looks like something is broken. I am always getting an error irrespective of > > the settings. > > Thanks for testing this, can you print with Firefox Release or a different > application? Update: The issue was seen on Nightly (BuildID:20160202030232). On further testing, I found that the issue has some other dependency. I updated the 'Tab Mix Plus' add-on to the latest Dev version instead of the latest release version and the issue was no longer seen (though a crash with signature https://crash-stats.mozilla.com/report/index/67527034-9eee-429f-8e83-7e9932160202 was seen after saving to PDF). This is puzzling, however, since I observed the issue earlier even in safe mode. Let me see if I can restore the old state and see if the issue still exists.
That crash looks like a different bug, I'll file that separately thanks.
Final Status: Could not reproduce issue reported earlier in comment 8. Problem not seen on latest Nightly (BuildID:20160202030232, UserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0) with e10s enabled, and default settings (i.e. print.print_via_parent = true, security.sandbox.content.level=2)
(In reply to ced from comment #12) > Final Status: > > Could not reproduce issue reported earlier in comment 8. > > Problem not seen on latest Nightly (BuildID:20160202030232, UserAgent: > Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0) > with e10s enabled, and default settings (i.e. print.print_via_parent = true, > security.sandbox.content.level=2) Thanks again. I'll see if the original poster can reproduce. Also, I've seen a possible issue while just testing, if I print first (after reboot) with the sandbox enabled on Windows 10. I'll do some more testing to see if it's a real problem.
(In reply to ced from comment #14) > Bob, I think you are right. > > Win10+security.sandbox.content.level=2+computer reboot->issue in comment 8 > seen > Win10+security.sandbox.content.level=0+computer reboot->issue in comment 8 > not seen Thanks for confirming this. It looks like there is a problem if the first interaction with the print device is from the sandboxed process. I'll have to debug to confirm. I'm going to assume that this is what caused the original problem. At some point I want to stop the child process from accessing the device completely, maybe I'll have to do that sooner rather than later.
I worked out what is going on here ... on Windows 10 (with 32-bit Firefox) instead of creating a low integrity 64-bit spool helper process the Printer Spooler service creates a medium integrity one, but it still picks up the access token settings from the sandboxed job. This helper then gets used by the main process (and other apps as well) and fails because of the USER_INTERACTIVE settings. I think I just need to get rid of print device access from the content process
For this bug, I want to start initiating printing through nsFrameLoader::Print, so that the interaction with the print driver for populating print settings can all happen on the parent. This will probably mean I can get rid of one of the nested event loops in the child and possibly the sync calls to save the settings as well. I've got some other things to do before I get to this, but I want to make a change to nsFrameLoader::Print to add the outer window ID I'll need for printing frames. This function is used by at least one add-on, so I want to make that change now in the same version it was added, so I'll file a blocking bug for this.
While it doesn't include all of the print set-up changes I described in comment 17, this should have been fixed by bug 1324064.
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Depends on: 1324064
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.