Is anybody there?

I see at "https://support.mozilla.org/en-US/questions/1155369?fpa=1" that there has been a change in the information shown by Help/About after this latest update -- in particular it now shows whether the 64-bit or 32-bit version is installed. This does not immediately bear on my question, however (unless the 51.0.1 update actually transformed my 64-bit version into the 32-bit version).

The fact remains that I was able to print from Firefox before the update but not after. I need either an explanation or troubleshooting advice. -- jclarkw

I help support an environment of around 3k machines and we have had several issues with clients who have upgraded to 51.0.1 and now get this same generic printer error. PDF's and web printing give the same result. Some people print fine after updating so it is not consistent. A refresh of FIrefox will fix the issue temporarily but we have verified that the issue comes back. It is very hard to troubleshoot since it is not consistent. Addons do not seem to be related to the issue. Any help would be appreciated. So far we have had 10 helpdesk tickets but I fear that many more will surface. IE & Chrome print fine.

bboy1234 said

...we have had several issues with clients who have upgraded to 51.0.1 and now get this same generic printer error. PDF's and web printing give the same result....

bboy1234 -- Thanks! I'm glad to hear I'm not the only one. It doesn't appear Mozilla is even acknowledging the problem yet.

Please tell me, are your clients running the 32-bit, 64-bit, or a mixture of versions of Firefox? Under what version(s) of Windows? -- jclarkw

x32 is on our base image, so I would say 100% x32

Try to reset the print prefs on the about:config page.

• https://support.mozilla.org/kb/how-print-website
• http://kb.mozillazine.org/Problems_printing_web_pages

You can open the about:config page via the location/address bar. You can accept the warning and click "I'll be careful" to continue.

• http://kb.mozillazine.org/about:config

resetting printing prefs via about:config had no impact

I'm also experiencing this issue, using 64-bit version of Firefox on Windows 7. Resetting the print prefs made no difference.

cor-el said

Try to reset the print prefs on the about:config page.

• https://support.mozilla.org/kb/how-print-website
• http://kb.mozillazine.org/Problems_printing_web_pages

You can open the about:config page via the location/address bar. You can accept the warning and click "I'll be careful" to continue.

• http://kb.mozillazine.org/about:config

As already reported by others, these debugging steps don't work, so please answer these questions:

1) Is there a way to roll Firefox back to version 50.1.0, or whatever is the most recent release in the 50... version? (50.1.0 is still printing properly on another similar computer on my network that I have refused to update.)

2) Prior to 51.0.1, is there a way to determine whether a Firefox version is 64-bit or 32-bit?

3) If I am indeed running the 32-bit version here, should it help me to replace it with the 64-bit version? Or is that functionally the same?

I cannot tolerate this situation indefinitely! -- jclarkw

1) Is there a way to roll Firefox back to version 50.1.0, or whatever is the most recent release in the 50... version? (50.1.0 is still printing properly on another similar computer on my network that I have refused to update.)

You can get it from FileHippo: <strike>32-bit</strike> or <strike>64-bit</strike>

2) Prior to 51.0.1, is there a way to determine whether a Firefox version is 64-bit or 32-bit?

I don't recall that, but at least with the links above you'll know which version you're running.

3) If I am indeed running the 32-bit version here, should it help me to replace it with the 64-bit version? Or is that functionally the same?

I was running the 64-bit version of 51.0.1 and it had the same problem as the 32-bit.

For now it seems like our best bet is to keep it on 50, or use the ESR Version instead, which is 45.7.0 currently. ¯\_(ツ)_/¯

(edited by moderator: please only post links to the Mozilla servers to download Firefox)

bigdoodr said

1) Is there a way to roll Firefox back to version 50.1.0, or whatever is the most recent release in the 50... version? (50.1.0 is still printing properly on another similar computer on my network that I have refused to update.)

You can get it from FileHippo: <strike>32-bit</strike> or <strike>64-bit</strike>

Thanks Much! Got it.

BTW, how did you find that earlier version? Evidently FileHippo is a useful site, but if I search for Firefox, I am offered only the latest (beta) version. -- jclarkw

bigdoodr said

1) Is there a way to roll Firefox back to version 50.1.0, or whatever is the most recent release in the 50... version? (50.1.0 is still printing properly on another similar computer on my network that I have refused to update.)

You can get it from [DELETED] or [DELETED]

Never mind -- I also found it here, courtesy of a Google search:

https://ftp.mozilla.org/pub/firefox/releases/

Thanks again. -- jclarkw

bigdoodr said

I'm also experiencing this issue, using 64-bit version of Firefox on Windows 7. Resetting the print prefs made no difference.

I just noticed another anomaly in 51.0.1: Adobe Flash doesn't work right. After the update from 50.1.0, Flash images "jitter" a lot.

I don't use Flash a lot, mind you, but I do use speedtest.net (which requires Flash) occasionally to monitor my Internet connection. The speed dial and the numbers break up into fragments, although the end result seems correct.

I realize that the Mozilla team is trying to eliminate plug-ins entirely, so they probably don't care, but it seems difficult to live completely without Flash given the number of Web sites out there that use it. They're just forcing me to fall back on Internet Explorer, as insecure as that is.

Anybody else noticed this issue? -- jclarkw

cor-el said

Try to reset the print prefs on the about:config page.

• https://support.mozilla.org/kb/how-print-website
• http://kb.mozillazine.org/Problems_printing_web_pages

You can open the about:config page via the location/address bar. You can accept the warning and click "I'll be careful" to continue.

• http://kb.mozillazine.org/about:config

I do hope somebody at Mozilla is taking the multiple problems with version 51.0.1 seriously (although there is little evidence of this at present). I don't mean to be a pest, but this is the first of many updates of Firefox that I have installed that has given me significant problems! -- jclarkw

I've filed the printing issue on Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1337413

Hopefully that will get it more traction with the devs.

Dear Management: A few days ago there was much more material on this thread, including some important answers and new questions, that has vanished on this "temporary site." I surely hope you have a way to reconstruct this material because I cannot reproduce even my part of it.

The original migration to Lithium did not go well (I suddenly became a "new user," and some of my older threads got truncated, among other things), and now we have this new disaster. It doesn't make Mozilla look too good, nor does it serve the users well! -- jclarkw

The more you post here, the more annoyed you are by switching back and forth, but enough about me.

This was your last reply on the Lithium thread:

jclarkw wrote:

To answer jscher2000's questions:

>>Are you using Multiprocess (e10s)?<<  Yes.  Test reports "1/1 (enabled by default)."

>>(3) Double-click the browser.tabs.remote.autostart.2 preference to switch the value from true to false...  At your next Firefox startup, it should run in the traditional way. Any difference in relation to printing (with sandbox on its default setting)?<<  Yes.  Printing works normally (but see below).

UPDATE OF PREVIOUS INFO:

I may not have mentioned this previously, but I normally run Firefox inside the Sandboxie sandbox, which apparently was a good security precaution some years ago but may no longer be necessary with Firefox's internal sandbox????

When I started these tests (now with 52.0.2 64-bit), I went first to an un-sandboxed version of Firefox and set security.sandbox.content.level back to its default value of 1 and restarted.  I also observed that browser.tabs.remote.autostart.2  was indeed set to its default value of "True."  This browser printed just fine!

Next I opened my customary Sandboxie version of Firefox, verified that these settings carried over as they should, and got the print error message that was my original complaint (some versions ago).  Now I can report that either security.sandbox.content.level = 0 or browser.tabs.remote.autostart.2 = false allows printing from within Sandboxie.  With both at their default values, however, I get the error message.

At this much later time I cannot be sure if I saw the original print error both inside and outside of Sandboxie, with and without bigdoodr's work-around, but I'm pretty sure I would have checked it both ways... -- jclarkw

I was able to extract the full thread to a PDF: https://www.jeffersonscher.com/temp/Cannot_Print-Lithium.pdf

I think what I was going to say about sandboxie is that they are aware that it is not fully compatible with multiprocess Firefox but I have no idea what they plan to do about it. When I searched around looking for a way to force both firefox.exe processes to run in the same sandbox, I didn't find any documentation on that. (Most people were asking how to run the same program twice in different sandboxes.)

jscher2000 said

I think what I was going to say about sandboxie is that they are aware that it is not fully compatible with multiprocess Firefox but I have no idea what they plan to do about it...

jscher2000 -- Thanks, that's helpful. Should I conclude then that the proper response to my printing problem is to leave

security.sandbox.content.level = 1

but to change to

browser.tabs.remote.autostart.2 = false

while we wait for Sandboxie to get its act together? -- jclarkw

OT -- They have recently issued a version that is compatible with Microsoft's click-to-run version of Office, so Outlook (in particular) can be run inside a sandbox. -- John W.

I think if Multiprocess is turned off, the sandboxing might not actually happen because there isn't a separate process on which to apply lower permissions/privileges. Anyway, since you're using Sandboxie, I think that provides your isolation and I don't have an opinion on which change makes the most sense.