Closed Bug 1152353 Opened 10 years ago Closed 8 years ago

FX 37.0.1 Printer Properties Freeze

Categories

(Core :: Printing: Setup, defect)

37 Branch
x86_64
Windows 7
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla55
Tracking Status
firefox-esr45 --- wontfix
firefox50 --- wontfix
firefox51 --- wontfix
firefox52 --- wontfix
firefox-esr52 --- verified
firefox53 --- wontfix
firefox54 --- verified
firefox55 --- verified

People

(Reporter: 357grizzly, Assigned: bobowen)

References

()

Details

(Keywords: crash, hang, Whiteboard: [tbird crash])

Crash Data

Attachments

(1 file)

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.
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?
Flags: needinfo?(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.
Flags: needinfo?(grizzly)
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).
(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
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".
(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.
OK. I got it. I ran the Package Manager and it installed mozregression.
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.
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.
I just installed v37.0 with a virgin profile and the problem is still there!
Do you have special plugins which may interfer with Firefox? Like HP plugins?
(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.
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.
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.
(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.
I think this is the same issue as in this bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=881620
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.
(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?
Flags: needinfo?(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.
Flags: needinfo?(rfmtm)
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.
Flags: needinfo?(grizzly)
Flags: needinfo?(grizzly) → needinfo?(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.
Flags: needinfo?(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.
(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.
Flags: needinfo?(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?
Flags: needinfo?(rfmtm)
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/
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?
Did you use mozregression? If yes, did you hit the issue with some builds?
Yes, I used mozzregression, but the problem did not go away, with any build I selected.
You started from which build number? 37? You can try from 30 or 35.
I went back to 30-31, which was way before I noticed this problem.
Are either of you still able to reproduce this in a current release?
Flags: needinfo?(rfmtm)
Flags: needinfo?(grizzly)
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.
Flags: needinfo?(rfmtm)
Flags: needinfo?(grizzly)
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.
(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?
Severity: normal → critical
Component: Untriaged → Printing: Setup
Flags: needinfo?(travis)
Keywords: hang
Product: Firefox → Core
See Also: → 881620
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.
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(travis)
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.
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.
Flags: needinfo?(bobowencode)
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.
Assignee: nobody → bobowencode
Flags: needinfo?(bobowencode)
I think the printing related crashes in bug 1243375 might also be to do with this issue.
Status: NEW → ASSIGNED
See Also: → 1243375
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/ :-)
(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.
Crash Signature: [@ shutdownhang | NtUserGetMessage | NtUserGetMessage | NtUserGetMessage | WaitForCompletionMessage | DocumentPropertiesWThunk ]
Keywords: crash
Whiteboard: [tbird crash]
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 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?
Attachment #8847700 - Flags: review?(jmathies) → review+
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/bobowencode@gmail.com-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.
Flags: needinfo?(rfmtm)
Flags: needinfo?(grizzly)
Pushed by bobowencode@gmail.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/471695817852 Repost printer properties completion messages after nsAppShell::ProcessNextNativeEvent. r=jimm
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
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 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.
Attachment #8847700 - Flags: approval-mozilla-beta?
Attachment #8847700 - Flags: approval-mozilla-aurora?
Hi Brindusa, could you help find someone to verify if this issue was fixed as expected on a latest Nightly build? Thanks!
Flags: qe-verify+
Flags: needinfo?(brindusa.tot)
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)?
Flags: needinfo?(gchang)
Flags: needinfo?(brindusa.tot)
Flags: needinfo?(bobowencode)
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.
Flags: needinfo?(bobowencode) → needinfo?(cosmin.muntean)
> 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.
Flags: needinfo?(cosmin.muntean)
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.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
Flags: needinfo?(gchang)
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.
Attachment #8847700 - Flags: approval-mozilla-beta? → approval-mozilla-beta-
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+.
Attachment #8847700 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment on attachment 8847700 [details] [diff] [review] Repost printer properties completion messages after nsAppShell::ProcessNextNativeEvent See comment 53.
Attachment #8847700 - Flags: approval-mozilla-esr52?
Let's make sure this works as intended on Fx54 as well.
Flags: qe-verify+
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
Attachment #8847700 - Flags: approval-mozilla-esr52? → approval-mozilla-esr52+
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.
I can confirm this issue is fixed, I verified using Firefox 52.1.2esr on Win 7 x64 build x32.
Flags: qe-verify+
Flags: needinfo?(rfmtm)
Flags: needinfo?(grizzly)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: