Firefox 15 freezes on printing PDF to Adobe PDF Creator printer
I just installed Firefox 15.0.1 on WIndows XP SP2. Also installed NoScript 2.5.5 and DownloadHelper 4.9.9, current Flash plugin and Shockwave.
The browser seems to print fine to all my physical printers. But when I attempt to print to the Adobe PDF printer driver, Firefox freezes. Windows XP's spooler reports that a job is being spooled to the queue but it seems Firefox never opens up the PDF WIndows File dialog to create and save the file. I must force-close Firefox from the Task Manager, it is frozen solid.
Upon force-close, Windows reports that a print job was sent to the Adobe PDF printer (I turned on notifications).
I have attempted running Firefox in Safe Mode. I have attempted to reset printer in about:config; I have removed all printer lines in prefs.js. I have disabled both plugins (the only 2 enabled when running in standard mode), I have checked Page Setup specs.
I have no crash ID as I must force-close the program in order to get out of it, it never recovers.
It seems from here that Firefox is failing to open up the File dialog for the PDF, and therefore it simply hangs waiting for the PDF driver to unlock it and return focus.
Any help would be appreciated! I am using the same version of the PDF converter driver on another machine, also running WIndows XP SP2, running Firefox 3.6, and it gives me no problems whatsoever.
Additional System Details
- Shockwave Flash 11.4 r402
- Adobe Shockwave for Director Netscape plug-in, version 184.108.40.2066
- McAfee MSC FF plugin DLL
- NPRuntime Script Plug-in Library for Java(TM) Deploy
- The QuickTime Plugin allows you to view a wide variety of multimedia content in Web pages. For more information, visit the QuickTime Web site.
- Npdsplay dll
- DRM Netscape Network Object
- DRM Store Netscape Plugin
- User Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20100101 Firefox/15.0.1
Oh, the Adobe PDF Converter is from Adobe Acrobat 7.0 Professional.
In some versions of Acrobat, there are two printers created. If you have one named "Distiller" could you try printing to that one?
You also could reset the printing preferences stored by Firefox.
(1) In a new tab, type or paste about:config in the address bar and press Enter. Click the button promising to be careful.
(2) In the filter box, type or paste printer and pause while the list is filtered
(3) Right-click print.print_printer and choose Reset. You can reset your Adobe PDF printer-specific settings as well, which will take many clicks....
Thanks for the reply.
I only have a single PDF printer showing, "Adobe PDF". I have already tried resetting the printer preferences as noted in the OP - no change.
Does document/page length make any difference?
Could you try a third party PDF printer driver to see whether they have the same problem catching the handoff from Firefox? For example:
It does not seem document length dependent - it happens everywhere, on every attempted page print, all the time.
I am wondering if this is a FF 15 bug, which is why I started this thread. No other program on 3 different computers using the Adobe print driver has ever shown this problem - this is the first, and only on this version of Firefox.
It certainly is possible that no one tested Firefox 15 with Acrobat 7 because it is a rather old version now. You could file a bug on it and see whether anyone recognizes it as being related to a known bug. This often is easier than searching through and reading all the existing bugs...
https://bugzilla.mozilla.org/ (separate registration from this forum)
However, in the meantime, if you can test another program that operates in a similar manner (i.e., captures print output to an external program to generate a PDF) that might help indicate whether the problem is Acrobat 7-specific or more general.
Thank you for your reply, jscher2000.
I have filed a bug report as per your recommendation. The Acrobat 7 driver does not have any problems with any other programs being used on 3 different machines, including several industry-specific custom apps I use. Only *this* version of FF, 15.0.1, seems to have this problem as even on FF 3.16 there is no issue.
I have FlashPaper and XPS Document print drivers also installed - I will test FF 15 on those to see the results.
OK, new information.
This seems to be a Firefox problem across alll program attempts to access Windows common dialogs. The "File / Open" command, the "File / "Save As" command and ALL attempts by Firefox to use the Windows common file handling dialogs fail.
I tried it with 15.0.1, and all dialog handling fails. I just regressed to 3.6.28...and *exactly* the same thing. NO other program on this system has this unusual problem - failed calls to Windows common file dialogs.
Just ran SFC, no change. Uninstalled McAfee, no change.
I would guess an invalid registry entry, but (of course) where to begin? I deleted all subkeys in HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32 as per a recommendation and that did not help, either.
It seems that Firefox, and Firefox alone, is calling common dialogs using a quite different procedural call than other programs. Anyone know?
Could you try installing Firefox 15.0.1 over your existing installation to refresh the program files.
First, I recommend backing up your Firefox settings in case something goes wrong. See Back up and restore information in Firefox profiles. (You can copy your entire Firefox profile folder somewhere outside of the Mozilla folder.)
When you revisit http://www.mozilla.com/ it may switch to the Mobile tab. Click the Desktop tab to download Firefox for desktop.
Of course, make sure all Firefox windows are fully closed before running the installer.
If dialogs still do not work, try using the Reset feature. This will discard some of the customizations that still are active in Safe Mode, while preserving bookmarks, history, saved passwords, and plugins (but not extensions). More information in this article: Refresh Firefox - reset add-ons and settings.
Restart Firefox in Firefox's Safe Mode using
Help > Restart with Add-ons Disabled
In the Safe Mode dialog, click "Reset Firefox".
Can Firefox save files?
I have reset before and just did so again, in Safe Mode. No change, Firefox can not open the Windows File common dialog.
Firefox properly saves and handles files using its own Download window. Firefox CANNOT save nor open files using any choices in the "File" menu option - can't Open or Save Page As. Also, *any* printer driver requiring the Windows File common dialog - PDF and XPS - all fail at the call to the common dialog.
I don't know why that process would fail; it seems completely routine for Win32 programs. COM objects can be blocked in the registry (at least in some contexts) by kill bits (and perhaps other methods), but then I would expect a more graceful handling of the situation.
Can you think of any reason that Firefox might be blocked from accessing Windows dialogs on that particular system, whether as a possible result of reduced permissions (i.e., run as a limited user), sandboxing, or firewall/program control features?
Normally I am indeed running as a limited user, but this problem also occurs when I am logged in on an administrator account (did so, just to make sure).
I have double-checked and overwritten permissions on the /Program FIles/Mozilla Firefox subdirectory, granting full access to Everyone with full inheritance to all subobjects - again, no change.
Someone reported this issue on Firefox 3
and this is the same type of symptom.
I have also been having this problem since upgrading to Firefox 15. It doesn't occur all the time but is extremely annoying because sometimes you don't have access to a physical printer and want to save something for later printing. The problem occurs when printing using Adobe pdf or another pdf creator called novaPDF, which I have installed. Firefox seems to have a problem opening the Windows Save As Dialog box. I was recommended to update to Ghostscript 9.06 because apparently it is used to generate the pdf file (sorry I am not sure if this is correct because I don't know very much about the exact mechanism of generating postscript files). So far it seems to have solved the problem but I will wait and see.