377336 - Printing a page results in Frozen App for a few minutes - Excessive data spooled to the Printer

Status: RESOLVED FIXED

(Core :: Printing: Output, defect)

Description

[Manoj]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a4pre) Gecko/20070410 Firefox/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a4pre) Gecko/20070410 Firefox/2.0

I was printing an email from mail.yahoo.com when I noticed this behavior. Firefox froze as it was "Preparing" for print and when it was done spooling the data to the printer, approximately 2 minutes had passed. It sent 5.6MB to the printer compared to IE7 that sent 1.04MB of data.

Reproducible: Always

Steps to Reproduce:
1. Open up your favorite webmail
2. Select a message
3. Print

Comment 1

[Manoj]

I have Firefox 2.0 on my laptop and it prints without exhibiting this behavior.

Comment 2

[Samuel Sidler (old account; do not CC)]

If there's a difference in the way Firefox prints on different systems, it sounds like a system problem. Can you try running Firefox with a new profile and see if it has the same problem? http://kb.mozillazine.org/Profile_Manager

Comment 3

[Manoj]

The difference isn't the behavior on different systems, it's the difference between versions 2.0 and 3.0.

Comment 4

[Manoj]

And this is on a machine with just one profile, the profile for Minefield.

Comment 5

[Samuel Sidler (old account; do not CC)]

Am I understanding correctly that you can't print with Minefield, but can with Firefox 2.0.0.3?

Comment 6

[Manoj]

I can print with Minefield and Firefox 2.0 (Bon Echo). The difference is, printing with Bon Echo is like printing with IE or for that matter, any other Windows application - www.yahoo.com/ is spooled to the printer within 10 seconds and approx 1.7MB is spooled to the printer. Printing www.yahoo.com/ with Minefield on a machine with just 1 profile (created specifically for MF) causes the process to freeze, and the app takes 2 or 3 minutes to spool 56MB of data to the printer.

Comment 7

[Samuel Sidler (old account; do not CC)]

Yeah, this sounds like something that would happen on the trunk, potentially due to Cairo and probably a dupe of an existing bug.

-> Core for triage.

Comment 8

[-fullmetaljacket-]

im about to file new bug but i saw this.

on my print testing for www.google.com:

IE7 spooled 1.04MB

minefield (build 20070605) spooled 4.85MB

[this maybe dup but i cant find one]

Comment 9

[Carsten Book [:Tomcat]]

works for me in Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9a6pre) Gecko/20070613 Minefield/3.0a6pre ID:2007061304 [cairo] and printing with google mail

Manoj, do you still the problem with a latest trunk (minefield) build ?

Comment 10

[-fullmetaljacket-]

for me, same amount of data spooled.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070613 Minefield/3.0a6pre ID:2007061316

Comment 11

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

(Windows bug, other platforms have their own similar bugs, but the underlying issues are different.)

Comment 12

[Steffen Wilberg]

I just printed a 50 KB text document with Minefield on Windows. It produced a 0.97 GB spool file and took around 20 minutes to print 6 pages (using WLAN to access the printer). Maximum memory consumption of firefox.exe was some 350 MB (up from 50 MB before printing), causing heavy swapping since this machine only has 512 MB RAM.

I then printed the same file with Bon Echo. It took around 5 seconds and the spool file was 1.5 MB or so.

I have to stop dogfooding Minefield at work because of this.

Comment 14

[Steffen Wilberg]

Attachment: testcase: 24 <h1> headings

24 <h1> headings to this wraps to two pages.
This 500 bytes file produces a 200 MB spoolfile.

Comment 15

[Steffen Wilberg]

Attachment: testcase: 10 <h1> headings

Unlike the previous attachment, this testcase doesn't exhibit the bug.
It only has 10 headings, which fit on one page.

Comment 16

[Damian Yerrick]

Related to bug 252694?

Comment 17

[Steffen Wilberg]

Comment on attachment 273415 [details]
testcase: 24 <h1> headings

Looks like bug 383960 (Cairo 1.5) fixed this testcase.

Comment 18

[Steffen Wilberg]

Attachment: testcase: <img hspace=375>

I reduced a large webpage to this:
<img hspace=375>

When trying to print, Firefox allocates several hundred MB RAM, causing heavy swapping. The value for hspace does matter, a lower value like 150 does not trigger the bug.

Comment 19

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: preliminary patch with thebes-only bits; depends on updated cairo

These are the win32-only bits from an upcoming patch; there is a dependency on getting cairo upgraded to the latest trunk before this can go in, but I wanted to see whether I'm doing the right things here.

Comment 21

[Stuart Parmenter]

Comment on attachment 279949 [details] [diff] [review]
preliminary patch with thebes-only bits; depends on updated cairo

please get rid of ShowPage -- cairo_show_page should be called from gfxWindowSurface::EndPage() when it is a printing surface

Make sure you msimg32 if it isn't already there to browser/app/Makefile.in (and the thunderbird app makefile, and seamonkey, etc..)

Comment 22

[Antti Kaihola]

Bug 395884 is about slow printing with Gran Paradiso on Linux. Related? There's also an attached test case to that bug.

Comment 23

[-fullmetaljacket-]

(In reply to comment #22)
> Bug 395884 is about slow printing with Gran Paradiso on Linux. Related? There's
> also an attached test case to that bug.
> 
see comment #11

Comment 24

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: updated patch

Ok, here's an updated patch.  Mostly cosmetic changes, taking advantage of new ShowPage() etc APIs.  Added msimg32 to browser/app/Makefile, not sure where to add it for the others.

Comment 25

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: updated patch

depends just on updated cairo.  A bit of code cleanup and some bugfixes to the win32 printing stuff; I'll upstream those but in a different form.

Comment 26

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Checked in; should be fixed.

Comment 27

[-fullmetaljacket-]

i tested it again at www.google.com, it now only takes 365KB spooled data and testcase had 20.5KB.

no more hanging

marking VERIFIED
 

Comment 28

[Steffen Wilberg]

I still see this bug. The testcase in attachment 275107 [details] created a 429 MB spool file before I managed to kill Minefield. Minefield used up to 350 MB RAM; before printing it was around 50 MB.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007092305 Firefox/3.0a8pre

Comment 29

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Can anyone else reproduce that?  I've tried with 2 different computers and 4 different printers and have had no problems on any of them.  The only thing I can think of is that it's a printer driver specific issue.

Comment 30

[Jo Hermans]

Attachment 275107 [details] produces a 113KB file for me on a HP Business Inkjet 2250 (PS mode).

Minefield still produces very large files in some cases, like in the url from bug 395677 : currently 4871KB instead of 2534KB in FF 2.0.0.6, but it used to be 7553KB on Septh 10th. The reason is that Cairo generates images, instead of printing strings. But it's nowhere near a 429MB file.

Comment 31

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Erm. so this patch somehow never actually got committed -- I just landed it now.  So please check that again with tomorrow's nightly?

Comment 32

[-fullmetaljacket-]

(In reply to comment #31)
> Erm. so this patch somehow never actually got committed -- I just landed it
> now.  So please check that again with tomorrow's nightly?
> 

weird, amount of spooled data goes down on my machine.

Comment 33

[Steffen Wilberg]

Much better :-)
Attachment 275107 [details] created only a 22,9 KB spool file, quick as on branch and without eating all my memory.
Marking fixed again.