248693 - Print and print preview hang with multiple <font><p> statements

Status: RESOLVED WORKSFORME

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

Description

[Sameer Gauriaa]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040614 Firefox/0.9
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040614 Firefox/0.9

When I click on print preview on the page above, it launches the window saying
"preparing" or equivalent and then just locks up and never recovers. I need to
"End Program".


Reproducible: Always
Steps to Reproduce:
1.Go to page listed above
2.Select File -> Print preview
3.

Actual Results:  
Application Crash.

Expected Results:  
Shown the pages to be printed.

This is similar to a lot of other bugs, but not identical, so I thought I should
file it. For reference the similar bugs can be seen at:
http://bugzilla.mozilla.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&field0-0-0=product&type0-0-0=substring&value0-0-0=print&field0-0-1=component&type0-0-1=substring&value0-0-1=print&field0-0-2=short_desc&type0-0-2=substring&value0-0-2=print&field0-0-3=status_whiteboard&type0-0-3=substring&value0-0-3=print&field1-0-0=product&type1-0-0=substring&value1-0-0=preview&field1-0-1=component&type1-0-1=substring&value1-0-1=preview&field1-0-2=short_desc&type1-0-2=substring&value1-0-2=preview&field1-0-3=status_whiteboard&type1-0-3=substring&value1-0-3=preview&field2-0-0=product&type2-0-0=substring&value2-0-0=crash&field2-0-1=component&type2-0-1=substring&value2-0-1=crash&field2-0-2=keywords&type2-0-2=substring&value2-0-2=crash&field2-0-3=short_desc&type2-0-3=substring&value2-0-3=crash&field2-0-4=status_whiteboard&type2-0-4=substring&value2-0-4=crash

Comment 1

[graham marshall]

(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7)
Gecko/20040614 Firefox/0.9
> Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7)
Gecko/20040614 Firefox/0.9
> 
> When I click on print preview on the page above, it launches the window saying
> "preparing" or equivalent and then just locks up and never recovers. I need to
> "End Program".
> 
> 
> Reproducible: Always
> Steps to Reproduce:
> 1.Go to page listed above
> 2.Select File -> Print preview
> 3.
> 
> Actual Results:  
> Application Crash.
> 
> Expected Results:  
> Shown the pages to be printed.
> 
> This is similar to a lot of other bugs, but not identical, so I thought I should
> file it. For reference the similar bugs can be seen at:
>
http://bugzilla.mozilla.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&field0-0-0=product&type0-0-0=substring&value0-0-0=print&field0-0-1=component&type0-0-1=substring&value0-0-1=print&field0-0-2=short_desc&type0-0-2=substring&value0-0-2=print&field0-0-3=status_whiteboard&type0-0-3=substring&value0-0-3=print&field1-0-0=product&type1-0-0=substring&value1-0-0=preview&field1-0-1=component&type1-0-1=substring&value1-0-1=preview&field1-0-2=short_desc&type1-0-2=substring&value1-0-2=preview&field1-0-3=status_whiteboard&type1-0-3=substring&value1-0-3=preview&field2-0-0=product&type2-0-0=substring&value2-0-0=crash&field2-0-1=component&type2-0-1=substring&value2-0-1=crash&field2-0-2=keywords&type2-0-2=substring&value2-0-2=crash&field2-0-3=short_desc&type2-0-3=substring&value2-0-3=crash&field2-0-4=status_whiteboard&type2-0-4=substring&value2-0-4=crash


I have the same with Firefox 0.9.1
View www.opticspages.com and print preview. Taskman shows 100% CPU time to Firefox.
Always reproducable.
Windows XP Pro.
Exactly the same happens in Moz 1.7 and looks like Bug 249748 so also commenting
there as well.

Comment 2

[u63580]

This is probably one for Core -> Printing.  I will try to come up with a testcase

Comment 3

[u63580]

Attachment: Testcase

I have created a testcase for this.  The page referenced has a series of <font
face=...> statements which are not closed before opening another, and another. 


Looks like it is related to bug 150431, but that is about just viewing pages,
not Print Preview.

Comment 4

[u63580]

The Summary could do to be altered to something like:

Print preview hangs with multiple nested <font><p> statements

Comment 5

[u63580]

Oh, by the way, the fact that the nested <font> statements are in a list seems
to be important too.  I suppose that should go in the summary, so perhaps:

Print preview hangs with multiple nested <font><p> statements in list items (<li>)

Comment 6

[Andreas Lange]

WFM. I can do print preview without any problems both with the URL and the
testcase on a current CVS suite build (1.8b2).

Comment 7

[alexanderz]

I can always reproduce this with firefox not responding.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050716
Firefox/1.0+

Comment 8

[Dennis]

Under FF 1.0.6, WinXP Home Edition SP2 and WinXP Pro

I'm having the same problem when trying to print preview www.yahoo.com.  I get
the dialog that says preparing to preview, but then FF hangs and the preview
page never appears.  Looking in Task manager, utilization for FF hits 99%. I
then need to terminate FF to gain control again.

This was also a problem under FF 1.0.5 and has occurred on 2 different machine
-- one a desktop and the other my laptop.

Comment 9

[Wayne Mery (:wsmwk)]

confirming fails Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1)
Gecko/20050904 SeaMonkey/1.1a for both testcase and 
http://indianheartjournal.com/JulAug03/Prudent%20Diet%20and%20Preventive/prudent_diet_and_preventive_nutr.htm

however, works in firefox Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.9a1) Gecko/20050903 Firefox/1.6a1

(www.opticspages.com now works in suite and FF - either the site morphed, or
something got fixed)

Comment 10

[Martijn Wargers (dead)]

The testcase is still hanging current trunk build on print preview for me (windowsXP).

Comment 11

[Stuart Parmenter]

this is not a regression (has happened since at least gecko 1.7) and I'm not sure this should block.  roc or dbaron can you take a look at this?  It looks like the hang is in reflow.

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I agree this shouldn't block. 

Comment 13

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (108 lines --> hang on print prev.)

This testcase has 108 copies of the line
<font><li><p>x</p></li>

On doing a print-preview for this testcase under linux, I get a hang, with this printed to STDOUT:
612.000000 792.000000
48960 63360


108 lines seems to be the magic cutoff for the hang -- see upcoming 107-line testcase.

Comment 14

[Daniel Holbert [:dholbert]]

Attachment: testcase 3 (107 lines --> bad numbering on print prev.)

This testcase is identical to the previous one but with 1 fewer line.

When viewing testcase 3 in print preview on Linux:
  - There's no hang -- yay!
  - BUT: the numbering is corrupted on pages 2-3, and is OK on pages 1 and 4.  (see upcoming postscript file for details -- specifically, page 2 starts at 29160 instead of 27, and page 3 starts at 30618 instead of 54)

It also looks like the 108th line, were it present, would fall on page 5.   That leads me to believe that the significance of 108 (see previous comment) is that it makes us use the 5th page, and that causes a hang somehow.

Comment 15

[Daniel Holbert [:dholbert]]

Attachment: print-to-PDF of testcase 3 (shows corrupt numbering)

Here's the results of printing attachment 296010 [details].  Note the corrupt numbering on pages 2 and 3.

Comment 16

[Daniel Holbert [:dholbert]]

Attachment: testcase 4 (54 lines --> 3 pgs, bad numbering on 2nd page of print prev)

This is just a reduced version of testcase 3.   When print-previewing this testcase on Linux, I see corrupt numbering on page 2.  (similar to that shown in the PDF attachment 296012 [details]).  In this case, the numbering on page 2 starts at 729, when it should start at 27.

The 54th line falls onto the 3rd page, and it's the presence of the 3rd page that seems to cause the problem here.  If I remove one line from the testcase, then we only use 2 pages, and the bad-numbering problem is fixed.

Comment 17

[Wayne Mery (:wsmwk)]

all testcase WFM using current trunk on vista