Closed Bug 110997 Opened 23 years ago Closed 19 years ago

Printing & Print Preview takes long time, and causes Mozilla to lock

Categories

(Core :: Printing: Output, defect, P3)

Product:
Core
Component:
Printing: Output
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: kleist, Unassigned)

References

(
URL
)

Details

(Keywords: perf, Whiteboard: [ADT3])

Attachments

(6 files)

This is the result of Print Preview on http://java.sun.com/
215.50 KB, application/vnd.ms-powerpoint
Details
This is a backtrace of the stack from GDB when mozilla crashed
3.65 KB, text/plain
Details
Original html with font tags.
83.28 KB, text/html
Details
Original Article without font tags.
99.77 KB, text/html
Details
Slightly simplified. Less tables with font tags.
85.99 KB, text/html
Details
Slightly simplified. Less tables without font tags.
83.73 KB, text/html
Details 
Build ID: 2001 11 20 03. Windows 2000.

Print Preview of the given URL takes more than twenty seconds
on my 850 MHz PIII machine. During this time no visual feedback is given
that a print formatting is going on, except that Mozilla locks completely.
Reporter here again: Please note that the document is barely 19 pages long,
and contains just a few images...

giving to rods
Assignee: dcone → rods
Does it come back after 19 seconds?
Keywords: perf
Yes. After rendering of the preview, everything went back to normal.

While we are figuring out what is making it slow, it might not be a bad thing to 
have it pop up a dialog for long pages. I don't think we should have a "Cancel" 
button on it. But it might not be too hard to have a progress meter.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → mozilla0.9.9
Build ID: 2001 12 10 03. Windows 2000.

I'm promoting this bug to "critical", since now Mozilla hangs and sucks 100% CPU
when I try to preview this page. I killed him after three minutes.
Severity: normal → critical
This takes just forever to reflow for PrintPreview. Something is up with 
InlineFrame reflow. I stopped in the debugger a couple of times. It's table 
related also.

It take forever to print also.
Assignee: rods → attinasi
Status: ASSIGNED → NEW
Target Milestone: mozilla0.9.9 → mozilla0.9.8
Summary: Print Preview takes long time, and causes Mozilla to lock → Printing & Print Preview takes long time, and causes Mozilla to lock
Build ID: 2001112009

Printing produces huge files.  Checking in the queue,
http://www.lgu.ac.uk/homepage.html is 5.07 MB, but when sent from IE 5.5 it is
only 296K. 

Netscape 6.2 does the same, btw.
*** Bug 115345 has been marked as a duplicate of this bug. ***
*** Bug 115047 has been marked as a duplicate of this bug. ***
OS: Windows 2000 → All
Hardware: PC → All
Print Preview on this page:
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/iis/maintain/default.asp
also appears to hang Moz 2001121508 on winxp.

This page has other pathological behaviors--the throbber won't stop, the stop
button doesn't seem effective, etc.--but I didn't try Print Preview until Moz
seemed otherwise "happy."
*** Bug 116524 has been marked as a duplicate of this bug. ***
On my machine (PIII700) a print preview on the given URL crashes mozilla
completely. Same for a print preview of www.heise.de.
*** Bug 116574 has been marked as a duplicate of this bug. ***
Print-Preview cause Mozilla to hang for me too, on this URL (sorry, really long,
it's a discussion forum):

http://arstechnica.infopop.net/OpenTopic/page?q=Y&a=tpc&s=50009562&f=28609695&m=300097118

It's mostly text, although there is some complex table layout.  IE Print Preview
shows it as being 17 pages, and pops up in less than ten seconds.  I gave up and
killed Mozilla after about 5 minutes.  This is on an Athlon XP 1800+ with 512MB
of RAM (about half that available).
*** Bug 118123 has been marked as a duplicate of this bug. ***
Print Preview of http://java.sun.com/ using Mozilla build 2002010403 causes the
screen image to be severely distorted; it also causes Mozilla to freeze
completely.  This is in a Windows 2000 environment.
Chris, can you check this out? From my debugging (brief) it seems like we are
spending a ton of time in nsTableOuterFrame::OuterReflowChild and the methods it
calls.  I am hoping you can use your reflow tools to figure out if this is table
or block pathology.
Assignee: attinasi → karnaze
->m099
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Status: NEW → ASSIGNED
Confiming problem using 2002020512 build on WinXP. It took 30seconds and layed
out 27pages in print preview for:
http://www.theserverside.com/resources/article.jsp?l=J2EE-vs-DOTNET

Marking nsbeta1+
Keywords: nsbeta1+
a reduced test case exhibiting similar behavior would be helpful.
Keywords: qawanted
This seems to be working much better with .9.7 builds!
Blake/Svante, is this working for you now? If so can we mark this
RESOLVED-WORKSFORME? I'll also c/o on my end.
Still takes c:a 20 seconds, using 2002 02 12 03. But I'll try again in a few days
with a newer build. I'll be back...
Amar will get reduced test case.
Okay I just tried it using the 2/13 build on Win 98 and it too me over
50 seconds to Print Preview that page. Definitely a performance hit.
 The problem with the given URL is it contains two <HTML> tags. One <HTML> tag 
insterted inside another. When I removed one <html> tag Print priview takes 2 
sec to show up.

Since I'm the one who once reported this alleged bug, I've written an email to
<rickard@middleware-company.com> who manages the site.

Product => tech.ev.
Component: Printing → US General
Product: Browser → Tech Evangelism
Target Milestone: mozilla0.9.9 → ---
Version: other → unspecified
This is a fairly common error. Should slightly screwed up tags cause a huge
performance hit? (I don't think so...)
I agree with Robert. This should NOT be "tech evangelism", but a perf bug.
OK, reverting to Browser/Print Preview...
Component: US General → Print Preview
Product: Tech Evangelism → Browser
Version: unspecified → other
Target Milestone: --- → mozilla1.0
Reassigning to parser based on comment #28.
Assignee: karnaze → harishd
Status: ASSIGNED → NEW
Component: Print Preview → Parser
QA Contact: sujay → moied
FYI: Parser does not deal with HTML tags in the document. In fact, it fabricates
one ( since HTML tag is optional ). I'm positive this has nothing to with the
parser.  

Back to layout
Assignee: harishd → attinasi
Component: Parser → Layout
QA Contact: moied → petersen
ok ok that sounded a bit rude ( sorry folks :-/ ). Let me investigate first and
then will assign it to the right party. Taking bug back :(
Assignee: attinasi → harishd
According to comment #28 the performance problem is due to an extra HTML tag. I
removed the extra HTML tag and the performance wasn't any better. With or
without the extra HTML tag it takes ~26 secs on my machine ( 1.2GZ, 512MB ). I'm
pretty sure this has got nothing to do with the extra HTML tag. Like I said
before, parser does not respect HTML tag in the document, since it's optional
per spec, instead it fabricates one ( and only one ).
The best thing to do is to use performance tools to pin point the problem. May
be dp@netscape.com/cathleen@netscape.com/nisheeth@netscape.com can help us out here.
ADT3 per ADT triage.
Whiteboard: [ADT3]
Tried to print preview the SOAP spec (http://www.w3.org/TR/soap12-part0/). The
CUPS printing dialog appeared and X freezed. I could still change to a console
and kill mozilla. Printing (without preview) works.

(I'm using Mozilla 0.9.9 on Mandrake Linux 8.1 on a P4 1,5GHz with 512MB.)
Running Mozilla Build ID 2002031808 on Linux on a pentium III 800 with 196 meg,
I was able to print preview the page from Microsoft listed above in about
comment 10.  I clicked the close button in the preview window and received a
segfault with the attached backtrace.  I don't know if this crash is related as
mozilla showed no performance problem.	In that it segfaults though, something
else may
be wrong.
I don;t think this is a parser problem. Unfortunately, I can't provide any clues
to where the problem could be since quantify does not cooperate and I don't have
a lot of time to spend on this bug. Giving bug to Cathleen for futher analysis.
Assignee: harishd → cathleen
I'll take a look at this on Thursday, using a spacetrace analysis.
More updates later.
I downloaded the Mozilla source for linux Today, compiled it and ran it under
GDB.  I'm not knowledgable about the code base but I'm not too bad with GDB. 
When I did a print preview of the microsoft URL from comment# 11 a failed
assertion (shown below) popped up in the debugging output.  I don't know if
it's related.  I tried print previewing the arstechnica example above from
comment #15 and also got the same assertion failed warning.  I did not however
get the assertion failed on http://www.google.com.  

setting printer name via 'MOZ_PRINTER_NAME='

PreWidth = 8.000000 PreHeight = 10.500000

Width = 576 Height = 756
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(NS_OpenURI(getter_AddRefs(in), uri)))
failed, file nsPostScriptObj.cpp, line 2829
###!!! ASSERTION: data loss - complete row needed more height than available, on
top of page: 'PR_FALSE', file nsTableRowGroupFrame.cpp, line 1116
###!!! Break: at file nsTableRowGroupFrame.cpp, line 1116

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email adt@netscape.com.  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1-
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email adt@netscape.com.  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1+
As of Linux Build 2002052309, I don't see any problem print previewing 
and Mozilla Doesn't crash for me when I close the print preview either.
This bug might be fixed on Linux.
Build ID: 2002-05-09-08. Windows 2000.

I visited the URL specified by this bug <
http://www.theserverside.com/resources/article.jsp?l=J2EE-vs-DOTNET >,
and did a print preview. Then I tried to visit my daily newspaper <
http://www.svd.se > (a page I have visited daily for several years,
and Mozilla has never crashed there AFAIK) and Mozilla crashed.

Incident ID: TB6774503M . Since these were the only actions I had done
since launching Mozilla, the crash may well be related to this bug.

More details about what I did to provoke the crash:

1. Launched Mozilla by clicking a link in my email program, opening this very
bug page.

2. Control-clicked the URL link in the header of the bug page <
http://www.theserverside.com/resources/article.jsp?l=J2EE-vs-DOTNET >
opening the page in a new Mozilla window.

3. Choosed  "Print Preview" from the "File" menu. I did _not_ close the print
preview page.

4. In the first Mozilla window, I pressed "Control+L" to select the URL field,
and entered "svd.se". The page to which I was redirected, <
http://svd.se/dynamiskt/ettan/did_1920592.asp > , was somewhat rendered (I
think) before Mozilla crashed.

Running Build 2002052309 I tried print previewing Svante's test case from
Comment #48 and the print preview menu hung around for serveral seconds before
disappearing and then the file menu remained in the pushed state for several
seconds until after about 15 seconds I killed mozilla with control C.  The slow
behaviour as reported in the bug appreas present and I was absolutely wrong in
comment #46 that the problem might be solved.  Sorry to inject a red herring
into debugging this.
This page take forever to layout for prniting/print preview. I didn't time it
but it is more than a miniute and then after it finally displays, when I press
"Close" it crashes walking the frame tree looking for images to start back up
the animation.

Something is very wrong with the initial reflow. I have sen on smoe pages where
the frame are created on one page and then get move to the next page. (See Bug
154136 for showing prgress dialogs during reflow.)
Assignee: cathleen → karnaze
Print Preview of a large complex page causes mozilla 1.1 to terminate on my
windows XP sp1 system.  Here is the page address: 

http://www.webreview.com/style/css1/charts/mastergrid.shtml
Also broken in 1.2a Build ID: 2002091014 Win2k sp3

http://www.webreview.com/style/css1/charts/mastergrid.shtml

Talkback ID: TB11281652Q
Mozilla 1.2a works in Linux, Suse 8.0
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910
For me it's new in mozilla1.2b. In mozilla1.2a print preview was working fine
and never hanging up. Only in mozilla1.2b everytime I try to preview printing
mozilla is doing nothing, you can only close mozilla with ctrl+alt+del.

For me it's not depending on the size of the document. If you want try the
following link to preview printing, it's only 3 kb:
http://fotogalerie.diethelm-schneider.de/index.htm
I tried, and mozilla was completly locked.

By the way, I use win98.
I just tested http://fotogalerie.diethelm-schneider.de/index.htm with today's
Windows build on Win98 and it worked fine in Print Preview.
Target Milestone: mozilla1.0 → ---
Priority: -- → P3
Target Milestone: --- → Future
Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.3) Gecko/20030310

Ok, I spend some time on this trying to come up with a simplified test case. 
During that, I discovered that if you pull all the font tags out of the document
the page goes to print preview in about 6 seconds, but with the tags it takes 55
seconds.

I'm attaching two test cases (not reduced) to show this.  I have no idea what
the cause is except perhaps that the markup in this document is invalid and does
not match the doctype.


Note:  The four attachments I sent in today were altered by my HTML editor.  I
did download the original source and pull the font tags out with notepad just
to make sure.

You will also notice there is a significant amount of time saved on the
versions with less tables when compared with the originals with all the layout
tables.  But in both cases the font tags have an effect on print preview.
mass reassign to default owner
Assignee: karnaze → table
Component: Layout → Layout: Tables
QA Contact: petersen → madhur
Target Milestone: Future → ---
Target Milestone: --- → Future
print bugs
Assignee: table → printing
Component: Layout: Tables → Printing
QA Contact: madhur → sujay
Target Milestone: Future → ---
Using:
Mozilla 1.4
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030714 Debian/1.4-2

I find that trying to print a web page or an email note brings up a Preparing....
panel that sits there forever;  an attempt to close it gives 'Mozilla is
not responding' Kill?
Print Preview hangs on this webpage and Firebird needs to be killed.

http://www.creativekitchenonline.com/story/waffles/recipes/belgian/

It is not a big document (probably 3 pages).
(In reply to comment #64)
> Print Preview hangs on this webpage and Firebird needs to be killed.
> 
> http://www.creativekitchenonline.com/story/waffles/recipes/belgian/

I've opened bug 263800 to deal with this issue and created a testcase for it.


Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a5) Gecko/20040930

I've tested all URLs listed on this page, and none of them (exception for the
one in comment 64) hang or crash Mozilla anymore on print preview.
I agree with James, all but #64 work fine for me now (Firefox 1.0 / Win XP).
(In reply to comment #67)
> I agree with James, all but #64 work fine for me now (Firefox 1.0 / Win XP).

Great, can we close this bug then?
Being the reporter of the bug, I *could* close it. But would that would be
appropriate? Maybe the assignee wants a word?
(In reply to comment #69)
> Being the reporter of the bug, I *could* close it. But would that would be
> appropriate? Maybe the assignee wants a word?

Sure, it's fine; most of the developers here are way too busy to look after
every single bug.  Plus, they could always reopen this bug if they disagree with
you.  Anyway, this bug's assignee is "printing@core.bugs", which is a type of
generic placeholder address given to bugs that have no real assignee.  So go
ahead and close it.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
I dont see any patch to this bug, so the resolution should be wfm.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → WORKSFORME
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: