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

VERIFIED FIXED in Firefox 54

Status

()

Core
Printing: Output
--
major
VERIFIED FIXED
a year ago
a year ago

People

(Reporter: whimboo, Assigned: cosmo0920)

Tracking

({regression})

54 Branch
mozilla55
Unspecified
Mac OS X
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox53 unaffected, firefox54+ verified, firefox55+ verified)

Details

Attachments

(3 attachments)

Created attachment 8870009 [details]
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?
Flags: needinfo?(haftandilian)
Flags: needinfo?(cosmo0920.oucc)
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?
Printing regression, tracking for 54/55.
tracking-firefox54: ? → +
tracking-firefox55: ? → +
Bob, do you know what might be up with this?  It might be related to bug 1364456?
Flags: needinfo?(bobowencode)
(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

a year 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)
(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

a year ago
Created attachment 8871260 [details] [diff] [review]
fix-paper-size-unit-handling.diff
Attachment #8871260 - Flags: review?(haftandilian)
(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.
Is there a way to get at least a single unit test added for this scenario?

Updated

a year ago
Assignee: nobody → cosmo0920.oucc
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+
Flags: needinfo?(haftandilian) → qe-verify?
Status: NEW → ASSIGNED
(Assignee)

Comment 11

a year 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.
(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)
(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.
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

a year 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?
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.
(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)
Leaving ni for myself to do a manual verification.
Flags: needinfo?(haftandilian)

Updated

a year ago
Duplicate of this bug: 1364456
Haik, have you verified your patch could fix the issue here?
(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

a year ago
It seems that Haik could confirm to fix this bug with my patch.
Can I add checkin-needed flag?
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

a year 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

a year 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.
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

a year ago
Created attachment 8875143 [details] [diff] [review]
Remove needless override

I guess that SetPaperSizeUnit should not be overridden in nsPrintSettingsX.
Attachment #8875143 - Flags: review?(haftandilian)
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)
(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

a year 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)
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.
tracking-firefox54: + → blocking
Flags: needinfo?(hskupin)
Flags: needinfo?(gchang)
Flags: needinfo?(cosmo0920.oucc)
(Assignee)

Comment 33

a year 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.
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)
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
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.
status-firefox54: affected → wontfix
tracking-firefox54: blocking → +
(Assignee)

Updated

a year ago
Flags: needinfo?(cosmo0920.oucc) → needinfo?(hskupin)
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

a year 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. :<
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.
Attachment #8875143 - Flags: review?(haftandilian) → review+
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

a year 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

a year ago
Keywords: checkin-needed

Comment 42

a year 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
https://hg.mozilla.org/mozilla-central/rev/00218a54f7e3
https://hg.mozilla.org/mozilla-central/rev/7dc72037b16f
Status: ASSIGNED → RESOLVED
Last Resolved: a year ago
status-firefox55: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
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?
Status: RESOLVED → VERIFIED
status-firefox55: fixed → verified
Flags: needinfo?(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.
status-firefox54: wontfix → affected
Flags: needinfo?(hskupin)
Flags: needinfo?(gchang)
Flags: needinfo?(brindusa.tot)
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)
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

a year ago
status-firefox56: --- → verified
This fix landed for 55 and not 56. So removing this flag to avoid confusion.
status-firefox56: verified → ---
status-firefox-esr52: --- → unaffected
Please nominate this for release so it's on the radar for dot-release consideration.
Flags: needinfo?(haftandilian)
This issue was fixed by bug 1364456 which was already nominated to release.
Please ignore the previous comment. Bug 1364456 was fixed by this one.
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 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 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+
Attachment #8875143 - Flags: approval-mozilla-release? → approval-mozilla-release+
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.
status-firefox54: fixed → verified
Flags: qe-verify?

Comment 57

a year 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.
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!
Also, feel free to provide links to any crash reports you've submitted.

Comment 60

a year 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

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

Comment 62

a year 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.