Closed
Bug 377336
Opened 18 years ago
Closed 17 years ago
Printing a page results in Frozen App for a few minutes - Excessive data spooled to the Printer
Categories
(Core :: Printing: Output, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: jhatax, Assigned: vlad)
References
Details
(5 keywords)
Attachments
(2 files, 4 obsolete files)
(deleted),
text/html
|
Details | |
(deleted),
patch
|
pavlov
:
review+
|
Details | Diff | Splinter Review |
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
I have Firefox 2.0 on my laptop and it prints without exhibiting this behavior.
Comment 2•18 years ago
|
||
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
The difference isn't the behavior on different systems, it's the difference between versions 2.0 and 3.0.
And this is on a machine with just one profile, the profile for Minefield.
Comment 5•18 years ago
|
||
Am I understanding correctly that you can't print with Minefield, but can with Firefox 2.0.0.3?
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•18 years ago
|
||
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.
Assignee: nobody → printing
URL: Non-specific
Component: General → Printing
Product: Firefox → Core
QA Contact: general
Updated•18 years ago
|
Keywords: regression
Comment 8•18 years ago
|
||
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]
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9?
OS: Windows Vista → All
Comment 9•18 years ago
|
||
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•18 years ago
|
||
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
Assignee | ||
Comment 11•18 years ago
|
||
(Windows bug, other platforms have their own similar bugs, but the underlying issues are different.)
OS: All → Windows XP
Assignee | ||
Updated•18 years ago
|
Assignee: printing → vladimir
Assignee | ||
Updated•17 years ago
|
Flags: blocking1.9? → blocking1.9+
Comment 12•17 years ago
|
||
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.
Keywords: dogfood
Comment 14•17 years ago
|
||
24 <h1> headings to this wraps to two pages.
This 500 bytes file produces a 200 MB spoolfile.
Comment 15•17 years ago
|
||
Unlike the previous attachment, this testcase doesn't exhibit the bug.
It only has 10 headings, which fit on one page.
Comment 16•17 years ago
|
||
Related to bug 252694?
Comment 17•17 years ago
|
||
Comment on attachment 273415 [details]
testcase: 24 <h1> headings
Looks like bug 383960 (Cairo 1.5) fixed this testcase.
Attachment #273415 -
Attachment is obsolete: true
Updated•17 years ago
|
Attachment #273416 -
Attachment is obsolete: true
Comment 18•17 years ago
|
||
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.
Assignee | ||
Comment 19•17 years ago
|
||
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.
Attachment #279949 -
Flags: review?(pavlov)
Comment 21•17 years ago
|
||
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..)
Attachment #279949 -
Flags: review?(pavlov) → review-
Comment 22•17 years ago
|
||
Bug 395884 is about slow printing with Gran Paradiso on Linux. Related? There's also an attached test case to that bug.
Comment 23•17 years ago
|
||
(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
Assignee | ||
Comment 24•17 years ago
|
||
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.
Attachment #281507 -
Flags: review?(pavlov)
Assignee | ||
Comment 25•17 years ago
|
||
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.
Attachment #279949 -
Attachment is obsolete: true
Attachment #281507 -
Attachment is obsolete: true
Attachment #281545 -
Flags: review?(pavlov)
Attachment #281507 -
Flags: review?(pavlov)
Updated•17 years ago
|
Attachment #281545 -
Flags: review?(pavlov) → review+
Assignee | ||
Comment 26•17 years ago
|
||
Checked in; should be fixed.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Comment 27•17 years ago
|
||
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
Status: RESOLVED → VERIFIED
Comment 28•17 years ago
|
||
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
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 29•17 years ago
|
||
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•17 years ago
|
||
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.
Assignee | ||
Comment 31•17 years ago
|
||
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•17 years ago
|
||
(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•17 years ago
|
||
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.
Status: REOPENED → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•