1152353 - FX 37.0.1 Printer Properties Freeze

Status: VERIFIED FIXED

(Core :: Printing: Setup, defect)

Description

[L.A.R. Grizzly]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20150402191859

Steps to reproduce:

When printing a page, FX freezes when I click on my Properties button in my printer dialog box. The first time clicked, the properties box will come up, but the freeze starts. If I close the properties box and hit the Properties button again, nothing happens. Going back to FX 36.0.4 has no problem and works fine. My printer works fine in other apps and SeaMonkey. This is new since updating to 37.0.1.

http://forums.mozillazine.org/viewtopic.php?f=38&t=2926961


Actual results:

FX freezes and can be closed, but just the interface closes. I have to kill firefox.exe through the Task Manager.


Expected results:

The printer properties box should appear to let me select the properties without freezing FX.

Comment 1

[Loic]

Did you test the basic stuff?
safe mode: https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode
new profile: https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

In addition, does it freeze if you select any printer, even virtual?

Comment 2

[L.A.R. Grizzly]

(In reply to Loic from comment #1)
> Did you test the basic stuff?
> safe mode:
> https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-
> mode
> new profile:
> https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-
> firefox-profiles
> 
> In addition, does it freeze if you select any printer, even virtual?

I didn't try Safe Mode. I did try it in a new clean profile with/without my security software enabled. It only happens with my HP printer. I have a ghostscript .pdf printer which works fine as well.

Comment 3

[Loic]

As you're probably the only one able to reproduce it (and maybe specific to this HP printer), could you download and run mozregression (see http://mozilla.github.io/mozregression/ for details about usage) to find a possible regression range, please.

If FF36 worked, start by "mozregression --good-release 36" (no need to bisect, the pushlog displayed in the shell is enough).

Comment 4

[L.A.R. Grizzly]

(In reply to Loic from comment #3)
> As you're probably the only one able to reproduce it (and maybe specific to
> this HP printer), could you download and run mozregression (see
> http://mozilla.github.io/mozregression/ for details about usage) to find a
> possible regression range, please.
> 
> If FF36 worked, start by "mozregression --good-release 36" (no need to
> bisect, the pushlog displayed in the shell is enough).

I looked over the program you mention and it's way beyond my understanding. I can use SeaMonkey if I really need to print a page with different properties. Maybe the next version of FX will alleviate the problem. BTW, I installed v37.0 and the problem is present, so it's between v36.0.4 and v37.0

Comment 5

[Loic]

Or maybe not. :)

Anyway it's really simple to use mozreg. it's a simple tool which (auto)download alpha builds (nightlies) by dichotomy to find the last good nightly and the first bad nightly.
Check the install doc: http://mozilla.github.io/mozregression/install.html
You need to install python 2.7 and use the command "pip" to install the mozreg package provided on that page.

After that, as FF36 worked, run mozreg with the command "mozregression --good-release 36".

Comment 6

[L.A.R. Grizzly]

(In reply to Loic from comment #5)
> Or maybe not. :)
> 
> Anyway it's really simple to use mozreg. it's a simple tool which
> (auto)download alpha builds (nightlies) by dichotomy to find the last good
> nightly and the first bad nightly.
> Check the install doc: http://mozilla.github.io/mozregression/install.html
> You need to install python 2.7 and use the command "pip" to install the
> mozreg package provided on that page.
> 
> After that, as FF36 worked, run mozreg with the command "mozregression
> --good-release 36".

OK. I installed AciveState, but I'm confused on what to do next. I opened up the Shell and typed: pip install -U mozregression but I get a Syntax error.

Comment 7

[L.A.R. Grizzly]

OK. I got it. I ran the Package Manager and it installed mozregression.

Comment 8

[L.A.R. Grizzly]

I figured out how to run the program. I ran the tests from v36.0 through 40.0a1 and didn't run into the problem during the tests.

Comment 9

[Loic]

It's weird, because you tried FF37 with a fresh profile and it was reproducible (in general, it's the best step to do to eliminate a bug in the profile).

Maybe try again FF37 with a fresh profile.

Comment 10

[L.A.R. Grizzly]

I just installed v37.0 with a virgin profile and the problem is still there!

Comment 11

[Loic]

Do you have special plugins which may interfer with Firefox? Like HP plugins?

Comment 12

[L.A.R. Grizzly]

(In reply to Loic from comment #11)
> Do you have special plugins which may interfer with Firefox? Like HP plugins?

No. Nothing has changed on my system since at least v36.0 (as far as Firefox and my printer). Check this out. I'm about to pull my hair out. I installed v36.0.4 with a virgin profile and the problem arose! I'm beginning to think that it's intermittent. I think I'll just live with it. I've been through myriads of tests and I can't seem to nail down what makes it happen. If I come up with anything else, I'll post back. Sheesh! Computers - Electronic time wasters.

Comment 13

[L.A.R. Grizzly]

After many hours of trying to track down my problem, I think I finally found the culprit. I had a corrupted Firewall Rules File. I don't know why this would have affected FX with my firewall turned off unless it had something to do with Loopback Zone. Anyway, after rebuilding my FW rules, I can't get FX to behave badly when clicking on my Properties button. I'll give it a few days and report back. If the problem is fixed, I'll ask that this bug be closed.

Comment 14

[Loic]

You probably set a (bad) rule in the firewall to forbid firefox.exe to access to the printer service, especially if your printer is shared on the LAN or with an access from outside.

Comment 15

[L.A.R. Grizzly]

(In reply to Loic from comment #14)
> You probably set a (bad) rule in the firewall to forbid firefox.exe to
> access to the printer service, especially if your printer is shared on the
> LAN or with an access from outside.

Well, the problem is still there. The problem is, that it is so infrequent. It only happened twice since my last post. It just happened a few minutes ago, so I thought I'd mention it. Maybe this bug should be closed seeing that tracking this down may be impossible.

Comment 16

[L.A.R. Grizzly]

I think this is the same issue as in this bug report:

https://bugzilla.mozilla.org/show_bug.cgi?id=881620

Comment 17

[rfmtm]

I'm also on W7-64, FX-38 and have the identical problem.

Printer Properties won't always open. After a fresh FX restart they will open at least once, but then either do nothing, or bring up an error (Not all printer functions available, or something similar). Trying to restart FX again usually crashes FX and logs an error report.

Safe Mode has no effect. Run as Administrator has no effect. Will do this with any installed printer even PDF printers. Reseting the printers had no effect. Only restarting FX allows at least one access sometimes more before the Printer Properties does not respond.

Comment 18

[Loic]

(In reply to rfmtm from comment #17)
> I'm also on W7-64, FX-38 and have the identical problem.
> 
> Printer Properties won't always open. After a fresh FX restart they will
> open at least once, but then either do nothing, or bring up an error (Not
> all printer functions available, or something similar). Trying to restart FX
> again usually crashes FX and logs an error report.
> 
> Safe Mode has no effect. Run as Administrator has no effect. Will do this
> with any installed printer even PDF printers. Reseting the printers had no
> effect. Only restarting FX allows at least one access sometimes more before
> the Printer Properties does not respond.

What's your printer? Does it work with virtual printer?

In addition, did it use to work in the past with previous versions on Firefox? Iy, yes, which one?

Comment 19

[rfmtm]

Same result no matter what printer is selected, Brother, HP, Dymo, or virtual printers like Foxit, DoPDF.

FX 36 and earlier all worked, never a problem.  FX 37,38 doesn't work.  Using W7-64 machine.  Trying it now on a W8 machine.

Comment 20

[Loic]

Thanks fo the feedback.

As you're able to reproduce the issue on your machine, could you find a regression range, please.
Check my comment #3 and comment #5 for details.

It will help a lot.

Comment 21

[rfmtm]

On a new W8 with a fresh install of FX 38.0.5, I still have the same basic problem.

On W8 it appears I can open the Printer Properties many more times before it stops working, which only sometimes I can do on W7.  Then after that fails it sometimes will still work from the Page Preview>Print, but not the File>Print.  Then it eventually hangs with the printer function not available error.  Sometimes just selecting another FX website Tab gets it going again, but usually have to restart FX.

Another note for both W7 & W8 if printing to Foxit or DoPDF, using the Browse function to select the file destination will also sometime just work once, and then stop working just like the Printer Properties button does.

Here is something else odd, after the Print Properties stopped working on this W7 machine, I noticed other Buttons not working, such as the Save Changes on this forum, until I restarted.  However, other buttons, tabs, etc., continued to work.

Comment 22

[rfmtm]

Another thing I have noticed, is when the Print Window opens, the hourglass appears for a few seconds, which it never use to.  Also when the Printer Properties fail, you never can just close Firefox normally, it is always hung and requires it to be canceled.

Doing a Google search of the problem, it appears it has been around for awhile, but certainly never affected me before now.  I have all the same printers and nothing really new or unusual on either my W7 or W8 machines.

Hope someone can find an answer, as this is really fouling me up at times.

Comment 23

[Loic]

(In reply to rfmtm from comment #22)

> Hope someone can find an answer, as this is really fouling me up at times.

We *really* need a regression range, here. As you're able to reproduce the issue, that's why I asked you to run the tool mozregression.

Comment 24

[rfmtm]

I can try the tool.  Is there also a place I can just download and reinstall a previous version of Firefox, which would seem a lot quicker to at least get a point of reference?

Comment 25

[Loic]

All the releases are available for each OS and language here:
http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/

If FF36 is the last release without your issue, that's this folder:
http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/36.0.4/win32/

Comment 26

[rfmtm]

Although it is not clear that I used the regression tool properly, from what I can tell going back well before where I remember it working, did not fix the problem.  

IE has no problem on the same machine opening printer properties of any printer in the list, only Firefox does. 

It also appears once the Printer Properties button stops working, so do any others associated with that tab, including refresh or any links on the displayed page.  However, the functions on another selected tab continue to work, just not the Properties button.

What's next to try and narrow down the problem?

Comment 27

[Loic]

Did you use mozregression? If yes, did you hit the issue with some builds?

Comment 28

[rfmtm]

Yes, I used mozzregression, but the problem did not go away, with any build I selected.

Comment 29

[Loic]

You started from which build number? 37?

You can try from 30 or 35.

Comment 30

[rfmtm]

I went back to 30-31, which was way before I noticed this problem.

Comment 31

[Ryan VanderMeulen [:RyanVM]]

Are either of you still able to reproduce this in a current release?

Comment 32

[rfmtm]

Yes, this still occurs, although less frequently with the new release, but more than enough to be a continued pain.  

Hard to pinpoint, as the same sequence of events may or may not trigger it every time, yet a slightly different sequence will.  It also sometimes feels like a timing issue, that waiting between steps alters whether it occurs or not.  

Still only occurs when using Firefox and once it happens FF will still not close normally and must be forced to do so and restarted.

With the new release of FF I have also noticed a long delay before the printer properties for a PDF virtual printer are retrieved.  You can see this easily with DoPDF8, which usually also will stop access to the properties of all printers, if you open the DoPDF8 properties more than once or twice.

Comment 33

[travis]

I have had this issue on a few computers in my office as well. Both have W7 64bit builds with multiple printers installed. The error can occur seemingly on any of the printers (even PDF). Safe Mode and Admin Mode don't solve anything. Printer drivers are all current and up to date. Have had this since Release 36 and possibly older but still occurs in current release.

Comment 34

[Wayne Mery (:wsmwk)]

(In reply to travis from comment #33)
> I have had this issue on a few computers in my office as well. Both have W7
> 64bit builds with multiple printers installed. The error can occur seemingly
> on any of the printers (even PDF). Safe Mode and Admin Mode don't solve
> anything. Printer drivers are all current and up to date. Have had this
> since Release 36 and possibly older but still occurs in current release.

travis, can you try mozregression mentioned in the prior coments?

Comment 35

[Mike Conley (:mconley) (:⚙️)]

So if somebody runs into this (assuming they're on Windows), what'd be super useful is a stack to see where the browser is "stuck".

There's this tool: https://ftp.mozilla.org/pub/utilities/crashfirefox-intentionally/ [1]

That, when run, should (I believe) crash Firefox in such a way as to cause the crash reporter to come up. If you submit your crash report, and then post a link to the report in about:crashes, then we'll have a stack to work with.

[1]: I'm uncertain if this will work with 64-bit OS's or 64-bit Firefox. If it doesn't, let me know, and I'll post a 64-bit build somewhere.

Comment 36

[Michelle Funches - QA]

Due to the amount of comments from developers, we will be changing the bug from Unconfirmed to New so that items with a component no longer display unconfirmed

Comment 37

[rfmtm]

This bug continues to exist, but pausing awhile between clicks almost always works.  In other words, click print, pause, click preferences, pause, click ok, pause, click ok to print. Otherwise it still hangs the browser.

Comment 38

[rfmtm]

This is getting worse, on FF 50.1.0.  Even long pauses between clicks doesn't help FF from hanging up after trying to access Printer Properties from a print window.  Yet opening the Properties from outside FF still works fine even while FF is still open.

Even closing and restarting FF didn't help today. Had to restart the computer as well.

Comment 39

[Bob Owen (:bobowen)]

I can get this to happen reasonably reliably by holding down the Ctrl key and then clicking the refresh button, followed by P twice very quickly.

Not all the symptoms are the same, but I think it is probably essentially the same problem.

What is happening is that although the Print dialogue closes, the message doesn't seem to have got back to winspool.drv!WaitForCompletionMessage.
So the call to ::PrintDlgW never completes.

However, winspool.drv!WaitForCompletionMessage is still pumping messages, so most things seem to work until you try to go back into print and click the Properties button.

When you try and shutdown, it returns as far as winspool.drv!WaitForCompletionMessage, but then it's stuck because it's never going to get the message it is waiting for.

I don't know how it is getting into this state, but my guess is that something else is picking up the message and dropping it for some reason.

I'll investigate further.

Comment 40

[Bob Owen (:bobowen)]

I think the printing related crashes in bug 1243375 might also be to do with this issue.

Comment 41

[Bob Owen (:bobowen)]

I can get this to reproduce on 37.0.1, 36.0.4 and even 3.0.19 [1] with the following STR.

So it looks like this potential issue has been around for a long time.
What I suspect has happened is that the e10s printing changes (which were about Fx37 and later), have made it much easier to get into this nested print dialog/properties state.
We possibly just need to prevent accessing print devices either directly or through another PrintDlg call, while we are already in PrintDlg.

STR:
These rely on using a fairly slow to complete loading page like www.bostonglobe.com
I imagine these could be reduced, but once you've got the hang of them  they're pretty easy to do.

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, you have to use Alt-enter in earlier versions).
3) Wait for a moment (less than second), until the page has started loading.
4) Press Ctrl-P (print dialog won't appear as page is loading).
5) Switch to original tab.
6) Press Ctrl-P (print dialog should appear immediately).
7) Wait for second print dialog to appear (when the second tab finishes loading).
8) Move second dialog, so you can see both print dialogs.
9) Click Properties... on second dialog (Properties dialog should appear).
10) Click Properties... on first dialog (which should appear to do nothing).
11) Click Cancel on first dialog.
12) Press Ctrl-P (which should give a message dialog saying printing is not available (message depends on version).
13) Click Cancel on second Properties dialog and then the Print dialog.
14) Click OK on the message dialog.

You should now get an unavailable message if you try and print on either of these tabs.
On a new tab the print dialog will appear, but the Propeties... button still does not work.
On shutdown it hangs.


[1] I only chose this one because the archive URL is http://archive.mozilla.org/pub/firefox/releases/3.0.19-real-real/ :-)

Comment 42

[Bob Owen (:bobowen)]

(In reply to Bob Owen (:bobowen) from comment #41)

> We possibly just need to prevent accessing print devices either directly or
> through another PrintDlg call, while we are already in PrintDlg.

I've tried this solution and while it helps with my STR, you can still get it into the same state when you have other modals displaying.

Comment 43

[mjb]

This happens at https://support.mozilla.org/t5/Firefox/firefox-crash-report/m-p/1369857#M1036305 as well.

Comment 44

[Bob Owen (:bobowen)]

After my initial try at fixing this failed, I found some time to look at this again this weekend.

After digging through the assembly, I found that while it is pumping windows events, it is checking for two hard coded (undocumented) messages 0x5b7a and 0x5b7f. These are posted to a WOW64 Thunk window that gets created as it opens the printer properties dialog, which is opened by the splwow64.exe process.

However that window doesn't process the messages, so when we pump them in a nested loop below their loop, they get lost. They only get picked up in the loop in winspool.drv.

Comment 45

[Bob Owen (:bobowen)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=746ee746b4f2

Comment 46

[Bob Owen (:bobowen)]

Attachment: Repost printer properties completion messages after nsAppShell::ProcessNextNativeEvent

Comment 47

[Jim Mathies [:jimm]]

Comment on attachment 8847700 [details] [diff] [review]
Repost printer properties completion messages after nsAppShell::ProcessNextNativeEvent

Review of attachment 8847700 [details] [diff] [review]:
-----------------------------------------------------------------

::: widget/windows/nsAppShell.cpp
@@ +24,5 @@
>  #include "GeckoProfiler.h"
>  #include "nsComponentManagerUtils.h"
>  #include "nsITimer.h"
>  
> +#define MOZ_WM_PRINTER_PROPERTIES_COMPLETION 0x5b7a

nit - Please add a comment to these explaining the values.

@@ +374,5 @@
>              IMEHandler::ProcessRawKeyMessage(msg)) {
>            continue;  // the message is consumed.
>          }
>  
> +        if (msg.message == MOZ_WM_PRINTER_PROPERTIES_COMPLETION ||

nit - comment me, what are we doing here?

Comment 48

[Bob Owen (:bobowen)]

Here's a talos comparison that doesn't seem to throw up any obvious issues:
https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=2fa181f64af6&newProject=try&newRevision=5a858494aa0e66a3a544426c7060c9ebecef9893&framework=1&showOnlyImportant=0

Comment 49

[Bob Owen (:bobowen)]

Hi both, before I land this, it would be great if either or both of you could confirm that it appears to fix the problem.

The try build (from comment 45) can be installed from here:
https://archive.mozilla.org/pub/firefox/try-builds/[e-mail]-5a858494aa0e66a3a544426c7060c9ebecef9893/try-win32/firefox-55.0a1.en-US.win32.installer.exe

If you want to protect your normal Firefox profile, you can run this newly installed version from the command line like this (this assumes you install it in the default location):

  "C:\Program Files (x86)\Nightly\firefox.exe" -no-remote -P

this will start the profile manager, so you can create a new one for this testing, thanks.

Comment 50

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/471695817852
Repost printer properties completion messages after nsAppShell::ProcessNextNativeEvent. r=jimm

Comment 51

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/471695817852

Comment 52

[Ryan VanderMeulen [:RyanVM]]

Gonna want to let this bake for awhile, but I think we should consider backporting it to affected branches once we're confident enough to do so.

Comment 53

[Bob Owen (:bobowen)]

Comment on attachment 8847700 [details] [diff] [review]
Repost printer properties completion messages after nsAppShell::ProcessNextNativeEvent

Approval Request Comment
[Feature/Bug causing the regression]:
As far as I can tell this problem has always been there, but it has been getting triggered more since at least Fx37. Possibly due to printing changes for e10s.

[User impact if declined]:
Users who hit the problem can no longer configure printing fully and possibly not print until Firefox is restarted. They will also hit the crash in bug 1243375 on shutdown.

[Is this code covered by automated tests?]:
No.

[Has the fix been verified in Nightly?]:
I have manually reproduced a version of the issue, using the STR in comment 41.
However we have not had confirmation from the original poster or the other user who could reproduce.
We've not had the related shutdown crash in Nightly, since it landed.
It occurred twice in the 3 or 4 days beforehand.

[Needs manual test from QE? If yes, steps to reproduce]:
It would be great to have this, particularly if they can reproduce with the details in the description.

[List of other uplifts needed for the feature/fix]:
None.

[Is the change risky?]:
Somewhat.

[Why is the change risky/not risky?]:
I think the only real risk is a performance one, but in the normal case this only adds a very small amount to the message processing.
I've also done talos runs and not seen any issues.
In the case where you actually get the problem we're trying to solve, we have to keep reposting the messages to the queue, but that has got to be better than losing them completely and the eventual crash.

[String changes made/needed]:
None.

Comment 54

[Gerry Chang [:gchang]]

Hi Brindusa, could you help find someone to verify if this issue was fixed as expected on a latest Nightly build? Thanks!

Comment 55

[Cosmin Muntean [:cmuntean], Ecosystem QA]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0
Firefox: 55.0a1, Build ID: 20170330030213

I have tested this issue on latest Nightly (55.0a1) build using a x32 and x64 version. For testing this I have used the STR provided in comment 41. On latest versions of Firefox (52 and above), a new step is required between Step 4 and Step 5 in order to reproduce the issue:

4) Press Ctrl-P (print dialog won't appear as page is loading).
4.1) Quickly  dismiss the "Cannot print this document yet, it is still being loaded" dialog.
5) Switch to original tab.

Here are the results:
- On latest Nightly (55.0a1) x32 bits version:

After following all the steps, which behave the same, the results have changed:
When you try to print either tabs, the "unavailable message" message is no longer displayed. 
The "Print" window is correctly opened and all the buttons work as expected. However, after the "Ok" button is clicked in order to print the page, 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. 
The same behavior can be observed even if you open a new tab and try to print the page. 
The print functionality will work again only if the browser is restarted.

Here is a screen recording with the issue: https://goo.gl/H9WC1o
Here is a screenshot with browser console errors displayed after the error occurred: https://goo.gl/6izxBp

- On latest Nightly (55.0a1) x64 bits version:
The same behavior described above. The differences between Nightly x32 and Nightly x64 bits can be observed when following the steps from comment 41:
- At step 10), the "Properties" window is opened.
- At step 13), the "Properties" window can not be closed only if the dialogs are closed first.
 
Here is a screen recording with the issue: https://goo.gl/VarAdG


Bob, Garry, I think the issue was partially fixed, now the "Print" window is correctly opened, but the page is not printed. Should we reopen this bug?
Also, is this issue only on Windows 7? Should I test other OS's (other Windows, Mac or Linux)?

Comment 56

[Bob Owen (:bobowen)]

Thanks for the testing.

(In reply to Cosmin Muntean [:CosminMCG] from comment #55)

> 4) Press Ctrl-P (print dialog won't appear as page is loading).
> 4.1) Quickly  dismiss the "Cannot print this document yet, it is still being
> loaded" dialog.

Ah yeah, you can just hit enter to close this for speed as well.
 
> The "Print" window is correctly opened and all the buttons work as expected.
> However, after the "Ok" button is clicked in order to print the page, 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. 

OK I'll look into this and see if I can reproduce.

> - On latest Nightly (55.0a1) x64 bits version:
> The same behavior described above. The differences between Nightly x32 and
> Nightly x64 bits can be observed when following the steps from comment 41:
> - At step 10), the "Properties" window is opened.
> - At step 13), the "Properties" window can not be closed only if the dialogs
> are closed first.

This is probably, because on 64-bit the properties windows is opened in the same process and not by the 64-bit helper process that is required for 32-bit printing on 64-bit Windows.
 
> Bob, Garry, I think the issue was partially fixed, now the "Print" window is
> correctly opened, but the page is not printed. Should we reopen this bug?

Does it at least fix the related shutdown hang (bug 1243375)?
If it does then we should probably file a follow-up for this new issue.
I suspect it is a related but different bug, particularly because you see it on 64-bit, which I don't think had the original problem.
Can you reproduce on current release 64-bit?

> Also, is this issue only on Windows 7? Should I test other OS's (other
> Windows, Mac or Linux)?

Just Windows and only Windows 7 (and before), certainly Windows 10 uses a different mechanism for exiting the nested event loop for the printer properties dialog.
Also I can only see the crash-stats data for Windows7 and a few before.

Comment 57

[Cosmin Muntean [:cmuntean], Ecosystem QA]

> Does it at least fix the related shutdown hang (bug 1243375)?
I haven't observed any crashes during testing. Also, I don't have any new "unsubmitted" or "submitted" crashes in "about:crashes".

> If it does then we should probably file a follow-up for this new issue.
> I suspect it is a related but different bug, particularly because you see it
> on 64-bit, which I don't think had the original problem.
> Can you reproduce on current release 64-bit?

On latest Firefox release (52.0.2 Build ID: 20170323105023) x64-bit, I haven't managed to reproduce either issues. The "Print" window is displayed and the page is correctly printed. So it seems that is indeed a different issue on Nightly.

I will log a follow-up bug for this and I will try to perform a regression-window.

Comment 58

[Cosmin Muntean [:cmuntean], Ecosystem QA]

The described issue in comment 41 is no longer reproducible on the latest Nightly (55.0a1 Build ID: 20170331030216) build. The Print window is correctly opened, the buttons work as expected on all tabs (even if I opened new ones) and I haven't encountered any crashes. 

I can confirm that on a older Nightly (2017-03-09) build, I was able to reproduce the issue and also I got a "ShutDownKill" crash after I have followed all the steps and I closed the browser.
Considering this, I will mark this issue as Verified - Fixed.

For the other issue, described in comment 55. I have logged a different bug 1352383.

Comment 59

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 8847700 [details] [diff] [review]
Repost printer properties completion messages after nsAppShell::ProcessNextNativeEvent

Too late for beta 53, but we could still potentially take this fix for 54.

Comment 60

[Gerry Chang [:gchang]]

Comment on attachment 8847700 [details] [diff] [review]
Repost printer properties completion messages after nsAppShell::ProcessNextNativeEvent

Fix a crash related to printer properties and was verified. Aurora54+.

Comment 61

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/cabc0989190a

Comment 62

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 8847700 [details] [diff] [review]
Repost printer properties completion messages after nsAppShell::ProcessNextNativeEvent

See comment 53.

Comment 64

[Andrei Vaida [:avaida]]

Let's make sure this works as intended on Fx54 as well.

Comment 65

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8847700 [details] [diff] [review]
Repost printer properties completion messages after nsAppShell::ProcessNextNativeEvent

ESR52 has e10s enabled and if e10s increases the likelihood of running into this bug, it's worth uplifting the fix to ESR52.2

Comment 66

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr52/rev/d893dea8e7b4

Comment 67

[Timea Zsoldos [:zstimi/tzsoldos], Desktop QA]

I have reproduced this issue using Firefox 55.0a1 (2017.03.09) on Win 7 x64 on build x32.
I can confirm this issue is fixed, I verified using Firefox 54.0b8 on Win 7 x64 build x32.

Comment 68

[Timea Zsoldos [:zstimi/tzsoldos], Desktop QA]

I can confirm this issue is fixed, I verified using Firefox 52.1.2esr on Win 7 x64 build x32.