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

Status: RESOLVED WORKSFORME

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

Description

[Karl Johan Kleist]

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.

Comment 1

[Karl Johan Kleist]

Reporter here again: Please note that the document is barely 19 pages long,
and contains just a few images...

Comment 2

[dcone (gone)]

giving to rods

Comment 3

[rods (gone)]

Does it come back after 19 seconds?

Comment 4

[Karl Johan Kleist]

Yes. After rendering of the preview, everything went back to normal.

Comment 5

[rods (gone)]

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.

Comment 6

[Karl Johan Kleist]

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.

Comment 7

[rods (gone)]

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.

Comment 8

[dylan_73]

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.

Comment 9

[R.K.Aa.]

*** Bug 115345 has been marked as a duplicate of this bug. ***

Comment 10

[R.K.Aa.]

*** Bug 115047 has been marked as a duplicate of this bug. ***

Comment 11

[Frank Burleigh]

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."

Comment 12

[Dimitrios]

*** Bug 116524 has been marked as a duplicate of this bug. ***

Comment 13

[ufechner]

On my machine (PIII700) a print preview on the given URL crashes mozilla
completely. Same for a print preview of www.heise.de.

Comment 14

[Matthias Versen [:Matti]]

*** Bug 116574 has been marked as a duplicate of this bug. ***

Comment 15

[Andrew Daugherity]

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).

Comment 16

[R.K.Aa.]

*** Bug 118123 has been marked as a duplicate of this bug. ***

Comment 17

[Dom Incollingo]

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.

Comment 18

[Dom Incollingo]

Attachment: This is the result of Print Preview on http://java.sun.com/

Comment 19

[Marc Attinasi]

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.

Comment 20

[karnaze (gone)]

->m099

Comment 21

[Kevin McCluskey (gone)]

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+

Comment 22

[karnaze (gone)]

a reduced test case exhibiting similar behavior would be helpful.

Comment 23

[Blake Learmonth]

This seems to be working much better with .9.7 builds!

Comment 24

[sujay]

Blake/Svante, is this working for you now? If so can we mark this
RESOLVED-WORKSFORME? I'll also c/o on my end.

Comment 25

[Karl Johan Kleist]

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

Comment 26

[sujay]

Amar will get reduced test case.

Comment 27

[sujay]

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.

Comment 28

[Amarendra Hanumanula]

 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.

Comment 29

[Karl Johan Kleist]

Since I'm the one who once reported this alleged bug, I've written an email to
<[e-mail]> who manages the site.

Product => tech.ev.

Comment 30

[Robert Turnbull]

This is a fairly common error. Should slightly screwed up tags cause a huge
performance hit? (I don't think so...)

Comment 31

[Olivier Zendra]

I agree with Robert. This should NOT be "tech evangelism", but a perf bug.

Comment 32

[Karl Johan Kleist]

OK, reverting to Browser/Print Preview...

Comment 33

[karnaze (gone)]

Reassigning to parser based on comment #28. 

Comment 34

[harishd]

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

Comment 35

[harishd]

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 :(

Comment 36

[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 ).

Comment 37

[harishd]

The best thing to do is to use performance tools to pin point the problem. May
be [e-mail]/[e-mail]/[e-mail] can help us out here.

Comment 38

[scottputterman]

ADT3 per ADT triage.

Comment 39

[Conny Krappatsch]

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.)

Comment 40

[Cameron Kellough]

Attachment: This is a backtrace of the stack from GDB when mozilla crashed

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.

Comment 41

[harishd]

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.

Comment 42

[Cathleen]

I'll take a look at this on Thursday, using a spacetrace analysis.
More updates later.

Comment 43

[Cameron Kellough]

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

Comment 44

[scottputterman]

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email [e-mail].  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.

Comment 45

[scottputterman]

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email [e-mail].  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.

Comment 46

[Cameron Kellough]

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.

Comment 47

[Karl Johan Kleist]

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.

Comment 48

[Karl Johan Kleist]

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.

Comment 49

[Cameron Kellough]

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.

Comment 50

[rods (gone)]

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.)

Comment 51

[Doug Thistlethwaite]

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

Comment 52

[Robert Turnbull]

Also broken in 1.2a Build ID: 2002091014 Win2k sp3

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

Talkback ID: TB11281652Q

Comment 53

[Robert Turnbull]

Mozilla 1.2a works in Linux, Suse 8.0
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910

Comment 54

[Diethelm Schneider]

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.

Comment 55

[rods (gone)]

I just tested http://fotogalerie.diethelm-schneider.de/index.htm with today's
Windows build on Win98 and it worked fine in Print Preview.

Comment 56

[Kevin Berkheiser]

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.

Comment 57

[Kevin Berkheiser]

Attachment: Original html with font tags.

Comment 58

[Kevin Berkheiser]

Attachment: Original Article without font tags.

Comment 59

[Kevin Berkheiser]

Attachment: Slightly simplified. Less tables with font tags.

Comment 60

[Kevin Berkheiser]

Attachment: Slightly simplified. Less tables without font tags.

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.

Comment 61

[karnaze (gone)]

mass reassign to default owner

Comment 62

[Bernd]

print bugs

Comment 63

[Michael Friendly]

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?

Comment 64

[Mark Lakata]

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).

Comment 65

[James Napolitano]

(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.

Comment 66

[James Napolitano]

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.

Comment 67

[Karl Johan Kleist]

I agree with James, all but #64 work fine for me now (Firefox 1.0 / Win XP).

Comment 68

[James Napolitano]

(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?

Comment 69

[Karl Johan Kleist]

Being the reporter of the bug, I *could* close it. But would that would be
appropriate? Maybe the assignee wants a word?

Comment 70

[James Napolitano]

(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 "[e-mail]", which is a type of
generic placeholder address given to bugs that have no real assignee.  So go
ahead and close it.

Comment 71

[José Jeria]

I dont see any patch to this bug, so the resolution should be wfm.