Closed
Bug 1366744
Opened 7 years ago
Closed 7 years ago
Printing (including save to PDF) mostly results in empty pages since bug 675709 has been fixed
Categories
(Core :: Printing: Output, defect)
Tracking
()
VERIFIED
FIXED
mozilla55
Tracking | Status | |
---|---|---|
firefox-esr52 | --- | unaffected |
firefox53 | --- | unaffected |
firefox54 | + | verified |
firefox55 | + | verified |
People
(Reporter: whimboo, Assigned: cosmo0920)
References
Details
(Keywords: regression)
Attachments
(3 files)
22.02 KB,
application/pdf
|
Details | |
2.78 KB,
patch
|
haik
:
review+
gchang
:
approval-mozilla-release+
|
Details | Diff | Splinter Review |
1.26 KB,
patch
|
haik
:
review+
gchang
:
approval-mozilla-release+
|
Details | Diff | Splinter Review |
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?
Flags: needinfo?(haftandilian)
Flags: needinfo?(cosmo0920.oucc)
Reporter | ||
Comment 1•7 years ago
|
||
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 3•7 years ago
|
||
Bob, do you know what might be up with this? It might be related to bug 1364456?
Flags: needinfo?(bobowencode)
Comment 4•7 years ago
|
||
(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).
Flags: needinfo?(bobowencode) → needinfo?(dholbert)
Assignee | ||
Comment 5•7 years ago
|
||
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.
Flags: needinfo?(cosmo0920.oucc)
Comment 6•7 years ago
|
||
(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!
Flags: needinfo?(dholbert)
Assignee | ||
Comment 7•7 years ago
|
||
Attachment #8871260 -
Flags: review?(haftandilian)
Comment 8•7 years ago
|
||
(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.
Reporter | ||
Comment 9•7 years ago
|
||
Is there a way to get at least a single unit test added for this scenario?
Updated•7 years ago
|
Assignee: nobody → cosmo0920.oucc
Comment 10•7 years ago
|
||
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.
Attachment #8871260 -
Flags: review?(haftandilian) → review+
Updated•7 years ago
|
Flags: needinfo?(haftandilian) → qe-verify?
Updated•7 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 11•7 years ago
|
||
(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.
Reporter | ||
Comment 12•7 years ago
|
||
(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.
Flags: needinfo?(haftandilian)
Reporter | ||
Comment 13•7 years ago
|
||
(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.
Assignee | ||
Comment 14•7 years ago
|
||
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.
Reporter | ||
Comment 15•7 years ago
|
||
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.
Assignee | ||
Comment 16•7 years ago
|
||
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?
Reporter | ||
Comment 17•7 years ago
|
||
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•7 years ago
|
||
(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.
Flags: needinfo?(haftandilian)
Comment 19•7 years ago
|
||
Leaving ni for myself to do a manual verification.
Flags: needinfo?(haftandilian)
Comment 21•7 years ago
|
||
Haik, have you verified your patch could fix the issue here?
Comment 22•7 years ago
|
||
(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.
Flags: needinfo?(haftandilian)
Assignee | ||
Comment 23•7 years ago
|
||
It seems that Haik could confirm to fix this bug with my patch. Can I add checkin-needed flag?
Reporter | ||
Comment 24•7 years ago
|
||
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
Assignee | ||
Comment 25•7 years ago
|
||
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.
Assignee | ||
Comment 26•7 years ago
|
||
(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.
Reporter | ||
Comment 27•7 years ago
|
||
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"?
Assignee | ||
Comment 28•7 years ago
|
||
I guess that SetPaperSizeUnit should not be overridden in nsPrintSettingsX.
Attachment #8875143 -
Flags: review?(haftandilian)
Comment 29•7 years ago
|
||
Gerry, do you think this (and bug 1364456) should block 54? We might still be able to get a patch in rc2 this week.
Flags: needinfo?(gchang)
Comment 30•7 years ago
|
||
(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?
Flags: needinfo?(cosmo0920.oucc)
Assignee | ||
Comment 31•7 years ago
|
||
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.
Flags: needinfo?(cosmo0920.oucc)
Comment 32•7 years ago
|
||
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.
Flags: needinfo?(hskupin)
Flags: needinfo?(gchang)
Flags: needinfo?(cosmo0920.oucc)
Assignee | ||
Comment 33•7 years ago
|
||
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.
Reporter | ||
Comment 34•7 years ago
|
||
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?
Flags: needinfo?(hskupin)
Reporter | ||
Comment 35•7 years ago
|
||
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.
Blocks: 675709
Comment 36•7 years ago
|
||
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.
Assignee | ||
Updated•7 years ago
|
Flags: needinfo?(cosmo0920.oucc) → needinfo?(hskupin)
Reporter | ||
Comment 37•7 years ago
|
||
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?
Flags: needinfo?(hskupin)
Assignee | ||
Comment 38•7 years ago
|
||
(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. :<
Reporter | ||
Comment 39•7 years ago
|
||
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.
Updated•7 years ago
|
Attachment #8875143 -
Flags: review?(haftandilian) → review+
Comment 40•7 years ago
|
||
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?
Assignee | ||
Comment 41•7 years ago
|
||
(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.
Assignee | ||
Updated•7 years ago
|
Keywords: checkin-needed
Comment 42•7 years ago
|
||
Pushed by ryanvm@gmail.com: 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
Keywords: checkin-needed
Comment 43•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/00218a54f7e3 https://hg.mozilla.org/mozilla-central/rev/7dc72037b16f
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
Reporter | ||
Comment 44•7 years ago
|
||
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•7 years ago
|
||
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.
Flags: needinfo?(hskupin)
Flags: needinfo?(gchang)
Flags: needinfo?(brindusa.tot)
Reporter | ||
Comment 46•7 years ago
|
||
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.
Flags: needinfo?(hskupin)
Comment 47•7 years ago
|
||
I verified this issue on Mac OS X 10.12 using FF Nightly 56.0a1 (2017-06-12) and I can confirm the fix.
Flags: needinfo?(brindusa.tot)
Updated•7 years ago
|
status-firefox56:
--- → verified
Reporter | ||
Comment 48•7 years ago
|
||
This fix landed for 55 and not 56. So removing this flag to avoid confusion.
status-firefox56:
verified → ---
Updated•7 years ago
|
status-firefox-esr52:
--- → unaffected
Comment 49•7 years ago
|
||
Please nominate this for release so it's on the radar for dot-release consideration.
Flags: needinfo?(haftandilian)
Comment 50•7 years ago
|
||
This issue was fixed by bug 1364456 which was already nominated to release.
Comment 51•7 years ago
|
||
Please ignore the previous comment. Bug 1364456 was fixed by this one.
Comment 52•7 years ago
|
||
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
Flags: needinfo?(haftandilian)
Attachment #8871260 -
Flags: approval-mozilla-release?
Comment 53•7 years ago
|
||
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
Attachment #8875143 -
Flags: approval-mozilla-release?
Comment 54•7 years ago
|
||
Comment on attachment 8871260 [details] [diff] [review] fix-paper-size-unit-handling.diff Fix a printing regression. Release54+. Should be in 54.0.1.
Attachment #8871260 -
Flags: approval-mozilla-release? → approval-mozilla-release+
Updated•7 years ago
|
Attachment #8875143 -
Flags: approval-mozilla-release? → approval-mozilla-release+
Comment 55•7 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-release/rev/6282c83320e2 https://hg.mozilla.org/releases/mozilla-release/rev/cc8b0ac8cc22
Comment 56•7 years ago
|
||
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.
Flags: qe-verify?
Comment 57•7 years ago
|
||
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•7 years ago
|
||
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•7 years ago
|
||
Also, feel free to provide links to any crash reports you've submitted.
Comment 60•7 years ago
|
||
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•7 years ago
|
||
Ryan, the problem has reappeared. I will file a new bug report. R.
Comment 62•7 years ago
|
||
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.
You need to log in
before you can comment on or make changes to this bug.
Description
•