1366744 - Printing (including save to PDF) mostly results in empty pages since bug 675709 has been fixed

Status: VERIFIED FIXED

(Core :: Printing: Output, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: example.pdf

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:55.0) Gecko/20100101 Firefox/55.0 ID:20170521030205 CSet: 5b74bbf20e803e299790d266fc6ebf5d53b7a1b7

When I try to print pages on MacOS, I most cases I get empty pages printed. This also reproduces when saving the page as PDF and let it open with Preview. This regressed between Firefox 53.0 and 54.0 currently in beta.

An example of where this happens is eg. https://secure3.hilton.com/en_US/hi/reservation/view/manage.htm. Just open it, and try to print.

I bisected the regression with mozregression and the result is the following:

21:34.09 INFO: No more inbound revisions, bisection finished.
21:34.09 INFO: Last good revision: 629a2481d51916ade2716a5155d0cee83475aaca
21:34.09 INFO: First bad revision: 17414d851efb55e58879157ef16f525a2e73ab0b
21:34.09 INFO: Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=629a2481d51916ade2716a5155d0cee83475aaca&tochange=17414d851efb55e58879157ef16f525a2e73ab0b

There is only one printing related change which is:

https://hg.mozilla.org/integration/mozilla-inbound/rev/dd49b1d1bf8f

and was landed via bug 675709. Hiroshi or Haik, can one of you please have a look at this?

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Just to note, it doesn't seem to happen with a fresh profile. So I believe that printing preferences as set in a version before 54.0, could be the cause here?

Comment 2

[Julien Cristau [:jcristau]]

Printing regression, tracking for 54/55.

Comment 3

[Nathan Froyd [:froydnj]]

Bob, do you know what might be up with this?  It might be related to bug 1364456?

Comment 4

[Bob Owen (:bobowen)]

(In reply to Nathan Froyd [:froydnj] from comment #3)
> Bob, do you know what might be up with this?  It might be related to bug
> 1364456?

This sounds similar to an issue we had on Windows when old invalid prefs (which happened not to cause problems because of other bugs previously) meant that we were getting very small page sizes, which triggered lots of blank pages.

From bug 1364456 it sounds like there might be a problem with bug 675709 that is causing the wrong page size.

I guess we should also detect when the page size is too small for us to render properly - NIing dholbert for this, as it seems like that check might have to be in layout.
I don't think we can just have a fixed limit, when I tried that originally I got people complaining as they used Firefox to print labels from the web (bug 1271900).

Comment 5

[Hiroshi Hatake [:cosmo0920]]

I'm writing a patch to resolve this regression.
I've found that the root cause of this bug.
In nsPrintSettingsX::GetEffectivePageSize, PaperSizeUnit always shall assume Inches.
kPaperSizeInche/PaperSizeMillimeters handling should split into another method to retrieve file printing page size.

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to Bob Owen (:bobowen) from comment #4)
> I guess we should also detect when the page size is too small for us to
> render properly - NIing dholbert for this, as it seems like that check might
> have to be in layout.

So you're suggesting we should enforce a minimum page size of some sort, or a maximum page-margin size as a percent of the page area, or something like that?  That seems like a reasonable way to limit the damage of bad/stale about:config pref data in general -- but I think that should be in our print logic (where we determine the page size & margins etc.), not in layout.

In any case, it sounds like this bug was a regression in how we handled existing pref data here, which we should fix, and Hiroshi is on top o ti -- thanks Hiroshi!

Comment 7

[Hiroshi Hatake [:cosmo0920]]

Attachment: fix-paper-size-unit-handling.diff

Comment 8

[Bob Owen (:bobowen)]

(In reply to Daniel Holbert [:dholbert] (reduced availability - travel & post-PTO backlog) from comment #6)
> (In reply to Bob Owen (:bobowen) from comment #4)
> > I guess we should also detect when the page size is too small for us to
> > render properly - NIing dholbert for this, as it seems like that check might
> > have to be in layout.
> 
> So you're suggesting we should enforce a minimum page size of some sort, or
> a maximum page-margin size as a percent of the page area, or something like
> that?  That seems like a reasonable way to limit the damage of bad/stale
> about:config pref data in general -- but I think that should be in our print
> logic (where we determine the page size & margins etc.), not in layout.
> 
> In any case, it sounds like this bug was a regression in how we handled
> existing pref data here, which we should fix, and Hiroshi is on top o ti --
> thanks Hiroshi!

Yes this is a more general catching of this issue, so I'll file a separate bug.
The reason why I think it might need to be in (or involve) layout, is that I think the minimum page size will have to depend on the content.
Some small page sizes might be OK for some content, but end up causing these sorts of issues for other pages.
Anyway, when I get round to filing the bug I'll try and come up with test cases to demonstrate that.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Is there a way to get at least a single unit test added for this scenario?

Comment 10

[Haik Aftandilian [:haik]]

Comment on attachment 8871260 [details] [diff] [review]
fix-paper-size-unit-handling.diff

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

This looks OK to me, but let's make sure we get thorough testing with printing in both inches-based locales and mm-based.

Comment 11

[Hiroshi Hatake [:cosmo0920]]

(In reply to Henrik Skupin (:whimboo) from comment #9)
> Is there a way to get at least a single unit test added for this scenario?

nsIWebProgressListener is not implemented in macOS. I have no idea to write unit test for this scenario.

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to Haik Aftandilian [:haik] from comment #10)
> This looks OK to me, but let's make sure we get thorough testing with
> printing in both inches-based locales and mm-based.

Who should check this patch? Just setting qe‑verify? might not be enough because people look for fixed bugs. So lets create at least a try build so that there is something we can use for testing.

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to Hiroshi Hatake [:cosmo0920] from comment #11)
> nsIWebProgressListener is not implemented in macOS. I have no idea to write
> unit test for this scenario.

Not implemented where? While I was working on Marionette's page load algorithm it was perfectly working fine for me on MacOS.

Comment 14

[Hiroshi Hatake [:cosmo0920]]

Oops, I mean that https://dxr.mozilla.org/mozilla-central/source/toolkit/components/printingui/mac/nsPrintingPromptService.cpp#86 and https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIPrintingPrompt.
In macOS, we cannot obtain printing progress in JavaScript code.

Comment 15

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Ok, so if you can get try to create a MacOS build I can test it. Sadly the patch is not a mozreview one, so it's more than a click away. Thanks.

Comment 16

[Hiroshi Hatake [:cosmo0920]]

I've built macOS nightly rev. 361917:aeb3d0ca558f and using https://bugzilla.mozilla.org/attachment.cgi?id=8871260.
But unfortunately dmg is too big to attach bugzilla.
I've uploaded in dropbox: https://www.dropbox.com/s/xa8hwww2u630npz/firefox-55.0a1.en-US.mac.dmg?dl=0
Could you test with this artifact?

Comment 17

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I like to use official builds. Also as it looks like you don't know Try, or have no access to do pushes. So I submitted a build request:

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

I will check it once the build is done.

Comment 18

[Haik Aftandilian [:haik]]

(In reply to Henrik Skupin (:whimboo) from comment #12)
> (In reply to Haik Aftandilian [:haik] from comment #10)
> > This looks OK to me, but let's make sure we get thorough testing with
> > printing in both inches-based locales and mm-based.
> 
> Who should check this patch? Just setting qe‑verify? might not be enough
> because people look for fixed bugs. So lets create at least a try build so
> that there is something we can use for testing.

I might have used the wrong flag. My intent was to get QE to do manual verification (in both types of locale) of this patch before it lands on release. The motivation for that is that the patch involves different calculations for millimeters and inches. Is there a better way to flag the bug for that? 

I'll do a manual verification myself and post results. I'll use the steps I used previously that you posted on <https://bugzilla.mozilla.org/show_bug.cgi?id=1364456#c17>. Leaving ni for myself to do that.

Comment 19

[Haik Aftandilian [:haik]]

Leaving ni for myself to do a manual verification.

Comment 21

[Peter Chang[:pchang]]

Haik, have you verified your patch could fix the issue here?

Comment 22

[Haik Aftandilian [:haik]]

(In reply to Peter Chang[:pchang] from comment #21)
> Haik, have you verified your patch could fix the issue here?

Yes (but it's Hiroshi's patch not mine.) With the prefs described on <https://bugzilla.mozilla.org/show_bug.cgi?id=1364456#c17>, the fix allows the print to work. Without the fix, my attempt to print results in a hang where the content process is using 100% CPU.

Comment 23

[Hiroshi Hatake [:cosmo0920]]

It seems that Haik could confirm to fix this bug with my patch.
Can I add checkin-needed flag?

Comment 24

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I checked the build from try with the patch applied but I still get those failures and hundreds of assertions like:

[Child 94584] ###!!! ASSERTION: Invalid computed height: 'aComputedHeight >= 0', file /home/worker/workspace/build/src/layout/generic/ReflowInput.cpp, line 351
[Child 94584] ###!!! ASSERTION: Invalid computed height: 'aComputedHeight >= 0', file /home/worker/workspace/build/src/layout/generic/ReflowInput.cpp, line 351
[Child 94584] ###!!! ASSERTION: Invalid computed width: 'aComputedWidth >= 0', file /home/worker/workspace/build/src/layout/generic/ReflowInput.cpp, line 327

Comment 25

[Hiroshi Hatake [:cosmo0920]]

Umm..., I can reproduce flood of assertions above.

But https://bugzilla.mozilla.org/show_bug.cgi?id=1364456#c17's is correct pref?

> user_pref("print.print_paper_height", "297.00");
> user_pref("print.print_paper_name", "iso_a4");
> user_pref("print.print_paper_size_type", 1);
> user_pref("print.print_paper_size_unit", 1);
> user_pref("print.print_paper_width", "210.00");

297.00 x 210.00 seems to be millimeter settings for iso_a4 paper.

Although, user_pref("print.print_paper_size_unit", 1) will specify inches.

Comment 26

[Hiroshi Hatake [:cosmo0920]]

(In reply to Hiroshi Hatake [:cosmo0920] from comment #25)
> Umm..., I can reproduce flood of assertions above.
> 
> But https://bugzilla.mozilla.org/show_bug.cgi?id=1364456#c17's is correct
> pref?
> 
> > user_pref("print.print_paper_height", "297.00");
> > user_pref("print.print_paper_name", "iso_a4");
> > user_pref("print.print_paper_size_type", 1);
> > user_pref("print.print_paper_size_unit", 1);
> > user_pref("print.print_paper_width", "210.00");
> 
> 297.00 x 210.00 seems to be millimeter settings for iso_a4 paper.
> 
> Although, user_pref("print.print_paper_size_unit", 1) will specify inches.

My bad, it is correct pref. Sorry for noise.

Comment 27

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Yes, I use A4 for printing. Not sure how any inch related settings went in here. Also why do we need this duplicated and maybe conflicting prefs "print.print_paper_name" and "print.print_paper_size_unit"?

Comment 28

[Hiroshi Hatake [:cosmo0920]]

Attachment: Remove needless override

I guess that SetPaperSizeUnit should not be overridden in nsPrintSettingsX.

Comment 29

[Julien Cristau [:jcristau]]

Gerry, do you think this (and bug 1364456) should block 54?  We might still be able to get a patch in rc2 this week.

Comment 30

[Haik Aftandilian [:haik]]

(In reply to Hiroshi Hatake [:cosmo0920] from comment #28)
> Created attachment 8875143 [details] [diff] [review]
> Remove needless override
> 
> I guess that SetPaperSizeUnit should not be overridden in nsPrintSettingsX.

Hiroshi, could you explain why? And how that fixes the ASSERT problem?

Comment 31

[Hiroshi Hatake [:cosmo0920]]

nsPrintOptions::DeserializeToPrintSettings handles paper size unit:
https://dxr.mozilla.org/mozilla-central/source/widget/nsPrintOptionsImpl.cpp#306

But current cocoa implementation is overridden unexpectedly.
I think we need to handle paper size unit in print.macosx.pagesetup-2.

Comment 32

[Gerry Chang [:gchang]]

Hi Henrik & Hiroshi,
Is this issue severe enough to impact all the Mac OS users? If yes, are we able to have a patch to fix the issue because we are about to have 54 RC2 and I would like to include this one?

As Julien suggested, mark 54 blocking for now.

Comment 33

[Hiroshi Hatake [:cosmo0920]]

I couldn't reproduce this issue with my current Firefox 53.0.3 profile's pref.js.
Note that my current profile's pref.js does not contain problematic settings which are commented in comment #25.

Comment 34

[Henrik Skupin [:whimboo][⌚️UTC+1]]

If those problematic preferences have been added a long time ago, this problem might only affect users who are with Firefox since years. I frankly do not know when those prefs have been added. It may also be that it is a result of moving my profile from a Linux machine to an OS X one. Someone familiar with the printing system should be a better resource to give a qualified answer.

A workaround would be to remove the offending preferences via about:config. So if it turns out to not become a blocker, maybe an item in the release notes would be good?

Comment 35

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Also we might have to weight-in the importance of the patch on bug 675709 which regressed this bug and bug 1364456. Whatever is more important to fix, but a backout of it should make this problem go away.

Comment 36

[Gerry Chang [:gchang]]

After discussing with Henrik, the issue seems caused by the pref combinations (in comment #25). Given such, the affected users might not as wide as we think. This might worth being documented. Thus, this no longer block 54. Mark 54 won't fix.

Comment 37

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I pushed another try build with both of the patches applied:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=916b9f7edeaad130644e2ded510ddb6298d867c8

A question beside... if the preferences which are causing this problem are not used anymore, is there a way to get them automatically removed? Or would users have to do it manually?

Comment 38

[Hiroshi Hatake [:cosmo0920]]

(In reply to Henrik Skupin (:whimboo) from comment #37)
> I pushed another try build with both of the patches applied:
> https://treeherder.mozilla.org/#/
> jobs?repo=try&revision=916b9f7edeaad130644e2ded510ddb6298d867c8
> 
> A question beside... if the preferences which are causing this problem are
> not used anymore, is there a way to get them automatically removed? Or would
> users have to do it manually?

In short, users needn't remove them when applying attached two patches in this bug.

Second patch restores old behavior for nsIPrintSettings#SetPaperSizeUnit in nsPrintOptions::DeserializeToPrintSettings.
It is also needed to fix this regression.

But, users will have to remove manually if only applying Haik reviewed patch.
If applying attached two patches, users will not need to remove problematic prefs.

Using both of patches applied build artifact, I succeeded to run "Open in Preview" and "Save as PDF".

I have no idea about this ancient problematic preferences. :<

Comment 39

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I can verify that the try build with both patches applied will fix both issues I'm currently facing with open in preview. Thank you Hiroshi for taking providing the patches.

Comment 40

[Haik Aftandilian [:haik]]

The second patch to remove the unneeded SetPaperSizeUnit seems fine, but the SetPaperSizeUnit method it overrides in nsPrintSettings has an identical implementation. So how does this have any effect?

Comment 41

[Hiroshi Hatake [:cosmo0920]]

(In reply to Haik Aftandilian [:haik] from comment #40)
> The second patch to remove the unneeded SetPaperSizeUnit seems fine, but the
> SetPaperSizeUnit method it overrides in nsPrintSettings has an identical
> implementation. So how does this have any effect?

This is because SetPaperSizeUnit override demands the following patch:

diff --git a/widget/cocoa/nsPrintOptionsX.mm b/widget/cocoa/nsPrintOptionsX.mm
--- a/widget/cocoa/nsPrintOptionsX.mm
+++ b/widget/cocoa/nsPrintOptionsX.mm
@@ -281,6 +281,9 @@ nsPrintOptionsX::DeserializeToPrintSetti
   settingsX->SetCocoaPrintInfo(newPrintInfo);
   [newPrintInfo release];
 
+  // Set paper size unit explicitly.
+  settingsX->SetPaperSizeUnit(data.paperSizeUnit());
+
   settingsX->SetAdjustedPaperSize(data.adjustedPaperWidth(),
                                   data.adjustedPaperHeight());
 
@@ -291,15 +294,15 @@ nsresult

But this approach increases pitfall for paper size unit.

The second patch just restores old behavior for SetpaperSizeUnit in nsPrintSettings.

It is used in https://dxr.mozilla.org/mozilla-central/source/widget/nsPrintOptionsImpl.cpp#306 and https://dxr.mozilla.org/mozilla-central/source/widget/nsPrintOptionsImpl.cpp#530.
Thus, we should not override this method in nsPrintSettingsX.

Comment 42

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/00218a54f7e3
Fix wrong PaperSizeUnit handling. r=haik
https://hg.mozilla.org/integration/mozilla-inbound/rev/7dc72037b16f
Remove needless SetPaperSizeUnit override. r=haik

Comment 43

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/00218a54f7e3
https://hg.mozilla.org/mozilla-central/rev/7dc72037b16f

Comment 44

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:55.0) Gecko/20100101 Firefox/55.0 ID:20170611030208 CSet: 799d43edb324395cf02da6b028e803712334615f 

I can verify that the landed patch fixed the problem. The page is getting printed fine with the preferences still set.

Gary, should we mark it as a ride-along patch in case we need another 54.0 security release?

Comment 45

[Gerry Chang [:gchang]]

Hi Henrik,
That's an option. Mark 54 back to affected.
Do you have STR for this so that QE can help verify or any tests you can suggest QE run?

NI Brindusa for the verification.

Comment 46

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I verified already that both known issues (this and bug 1364456) are fixed for 55.0. I'm happy to do the same verification steps once we uplifted the patches for release. STR (including the necessary prefs) are layed out too.

Comment 47

[ovidiu boca[:Ovidiu]]

I verified this issue on Mac OS X 10.12 using FF Nightly 56.0a1 (2017-06-12) and I can confirm the fix.

Comment 48

[Henrik Skupin [:whimboo][⌚️UTC+1]]

This fix landed for 55 and not 56. So removing this flag to avoid confusion.

Comment 49

[Ryan VanderMeulen [:RyanVM]]

Please nominate this for release so it's on the radar for dot-release consideration.

Comment 50

[Gerry Chang [:gchang]]

This issue was fixed by bug 1364456 which was already nominated to release.

Comment 51

[Gerry Chang [:gchang]]

Please ignore the previous comment. Bug 1364456 was fixed by this one.

Comment 52

[Haik Aftandilian [:haik]]

Comment on attachment 8871260 [details] [diff] [review]
fix-paper-size-unit-handling.diff

Approval Request Comment
[Feature/Bug causing the regression]:
[User impact if declined]:
[Is this code covered by automated tests?]:
[Has the fix been verified in Nightly?]:
[Needs manual test from QE? If yes, steps to reproduce]: 
[List of other uplifts needed for the feature/fix]:
[Is the change risky?]:
[Why is the change risky/not risky?]:
[String changes made/needed]:

Approval Request Comment

[Feature/Bug causing the regression]:
Bug 675709 - printToFile is busted on Mac

[User impact if declined]:
Some uncommon printing pref combinations can cause Firefox to hang on Mac when print or print-to-file is attempted.

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

[Has the fix been verified in Nightly?]:
Yes.

[Needs manual test from QE? If yes, steps to reproduce]:
Yes. Use the pref combination posted on https://bugzilla.mozilla.org/show_bug.cgi?id=1364456#c17 :
Add the following to prefs.js of a fresh profile:
user_pref("print.print_paper_height", "297.00");
user_pref("print.print_paper_name", "iso_a4");
user_pref("print.print_paper_size_type", 1);
user_pref("print.print_paper_size_unit", 1);
user_pref("print.print_paper_width", "210.00");

[List of other uplifts needed for the feature/fix]:
Both patches posted to this bug.

[Is the change risky?]:
Medium to low risk.

[Why is the change risky/not risky?]:
The change is small, but printing is not covered by automated tests.

[String changes made/needed]:
None

Comment 53

[Haik Aftandilian [:haik]]

Comment on attachment 8875143 [details] [diff] [review]
Remove needless override

Approval Request Comment

[Feature/Bug causing the regression]:
Bug 675709 - printToFile is busted on Mac

[User impact if declined]:
Some uncommon printing pref combinations can cause Firefox to hang on Mac when print or print-to-file is attempted.

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

[Has the fix been verified in Nightly?]:
Yes.

[Needs manual test from QE? If yes, steps to reproduce]:
Yes. Use the pref combination posted on https://bugzilla.mozilla.org/show_bug.cgi?id=1364456#c17 :
Add the following to prefs.js of a fresh profile:
user_pref("print.print_paper_height", "297.00");
user_pref("print.print_paper_name", "iso_a4");
user_pref("print.print_paper_size_type", 1);
user_pref("print.print_paper_size_unit", 1);
user_pref("print.print_paper_width", "210.00");

[List of other uplifts needed for the feature/fix]:
Both patches posted to this bug.

[Is the change risky?]:
Medium to low risk.

[Why is the change risky/not risky?]:
The change is small, but printing is not covered by automated tests.

[String changes made/needed]:
None

Comment 54

[Gerry Chang [:gchang]]

Comment on attachment 8871260 [details] [diff] [review]
fix-paper-size-unit-handling.diff

Fix a printing regression. Release54+. Should be in 54.0.1.

Comment 55

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-release/rev/6282c83320e2
https://hg.mozilla.org/releases/mozilla-release/rev/cc8b0ac8cc22

Comment 56

[Bogdan Maris, Desktop QA]

Reproduced the initial issue using 54.0 and steps from comment 53, verified that the issue is fixed using 54.0.1 on macOS 10.12.5, Windows 10 64bit, Ubuntu 16.04 32bit.

Comment 57

[Richard Beeson]

The print to PDF bug is not fixed. It is broken. I print online orders to PDF, and have been doing so for years with no problem. Suddenly, with 54.0.1 64 bit, the browser crashes every time I try to navigate to a folder to save the PDF. The only way I can save it at all is to save to desktop, then transfer it to the proper folder later, and this doesn't work when I'm adding a page to an existing PDF. I use Nuance PDF Creator for making PDFs. Firefox has just become nearly totally useless for any kind of printing. I will have to switch to IE until this is fixed. I have filed multiple crash reports, and there has been no response, and no fix.

Comment 58

[Ryan VanderMeulen [:RyanVM]]

Richard, please file a new bug for specific sites you're having difficulties with (and please CC me when you do!). These issues can often manifest with similar symptoms but entirely different root causes and therefore need to be investigated on a case-by-case basis. Otherwise, tracking issues becomes nearly impossible. Thanks!

Comment 59

[Ryan VanderMeulen [:RyanVM]]

Also, feel free to provide links to any crash reports you've submitted.

Comment 60

[Richard Beeson]

Ryan, I did more testing. I cleared the cache and cookies several times. I printed to PDF from IE. I printed to my normal printer from FF. Then I went back to attempting to print to PDF. The problem seems to have cleared up. It was happening mostly on Amazon, but also on other sites. Perhaps it was caused by a recent upgrade (2 days ago) from MalwareBytes 2.x to 3.x, which is more aggressive. But I wasn't getting any messages from MBAM. One of those mysteries. If the problem stays fixed, I'll leave it alone. If it returns, I'll file a new report. Thanks for getting back to me.

Comment 61

[Richard Beeson]

Ryan, the problem has reappeared. I will file a new bug report. R.

Comment 62

[Richard Beeson]

Ryan, I have submitted the new bug. It is bug # https://bugzilla.mozilla.org/show_bug.cgi?id=1386788. I put links to the crash reports in the bug report. If you need me to upload more files, please let me know what you need.