Closed Bug 194330 Opened 22 years ago Closed 21 years ago

crash on trying to print or print preview the above url

Categories

(Core :: Printing: Output, defect)

Product:
Core
Component:
Printing: Output
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: noel.clarkson, Assigned: john)

References

(
URL
)

Details

(Keywords: hang, testcase)

Attachments

(4 files, 1 obsolete file)

stacktrace
26.59 KB, text/plain
Details
Minimized Testcase
388 bytes, text/html
Details
Patch v0.9
842 bytes, patch
Details | Diff | Splinter Review
Patch
897 bytes, patch
karnaze
: review+
kinmoz
: superreview+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.2.1) Gecko/20021130
Build Identifier: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.2.1) Gecko/20021130

The above url causes mozilla to freeze and need an alt-ctl-del and end task to
get back from it when you try to print or print preview it (freezes on preparing).

Reproducible: Always

Steps to Reproduce:
1. Open Browser
2. Go to http://ato.gov.au/content/notforprofit/29723.htm
3. Try to Print, or Print Preview
Actual Results:  
mozilla freezes

Expected Results:  
Printed or Previewed the print job

I've also seen this in 1.2.1 running on Win98
Just tried this on Moz 1.3b (2003021008) on Win95.  I now get a print preview
ok, but still get a freeze on printing.
Another url that crashes while trying to print it is
http://netscape.com.com/2102-1104-985644.html.

Steps to reproduce:

1) Load above url.
2) Chose File, Print from the menu.
3) You'll see a dialog that says "Preparing to print".  Then the browser crashes.

Confirming bug...  

Suggesting that this be considered a 1.3 blocker because crashing while printing
pages on ZDNet will hit a lot of users.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.3?
Attached file stacktrace — 
stack from linux CVS debug

I also get this over and over:
###!!! ASSERTION: running past end: 'mCurrent != mListLink', file nsLineBox.h,
line 562
###!!! ASSERTION: running past end: 'mCurrent != mListLink', file nsLineBox.h,
line 562
###!!! ASSERTION: data loss - incomplete row needed more height than available,
on top of page: 'rowMetrics.height <= rowReflowState.availableHeight', file
nsTableRowGroupFrame.cpp, line 1143
WARNING: Can not find a widget for the parent view, file nsViewManager.cpp,
line 2338
WARNING: Can not find a widget for the parent view, file nsViewManager.cpp,
line 2338
WARNING: Can not find a widget for the parent view, file nsViewManager.cpp,
line 2338
WARNING: Can not find a widget for the parent view, file nsViewManager.cpp,
line 2338
WARNING: Can not find a widget for the parent view, file nsViewManager.cpp,
line 2338
WARNING: Can not find a widget for the parent view, file nsViewManager.cpp,
line 2338
WARNING: Can not find a widget for the parent view, file nsViewManager.cpp,
line 2338
WARNING: Can not find a widget for the parent view, file nsViewManager.cpp,
line 2338
WARNING: Can not find a widget for the parent view, file nsViewManager.cpp,
line 2338
Attached file testcase (obsolete) — 
testcase hangs linux trunk 20020324
Keywords: hang, testcase
OS: Windows 95 → All
-> jkeiser
Assignee: rods → jkeiser
Attached file Minimized Testcase — 
This is the minimized version of the previous testcase.  It appears that for a
100% height table with a huge rowspan in it and cells before and after the
rowspan (vertically), we create an infinite number of next-in-flow frames for
some reason.

Should height=100% under <body> even apply during printing?  What would it
possibly mean?
Attachment #115461 - Attachment is obsolete: true
bernd may have insight on this.
Status: NEW → ASSIGNED
> Should height=100% under <body> even apply during printing?  What would it
> possibly mean?

For printing, I would probably make 100% equivalent to the size of a page, or
just chuck it and switch to auto height.
kin wrote:
> > Should height=100% under <body> even apply during printing?  What would it
> > possibly mean?
>
> For printing, I would probably make 100% equivalent to the size of a page, or
> just chuck it and switch to auto height

Chuck it, please (otherwise we'll get the "table always prints on new page,
leaving the previous page half blank"-bug spam again).
If people really want to cover one page with a table they should use CSS@page
for that.
OK, I have tracked this down to
http://lxr.mozilla.org/seamonkey/source/layout/html/table/src/nsTableRowGroupFrame.cpp#1194
... specifically, it is getting 45, the height of the other two row frames.  It
seems to me that this code is universally wrong--the height of the row might be
dependent on the height of the previous row, but will certainly not be equal to it.
John,

now that you are so close to a patch, there is one (secret) thing  you need to
know. 

There are printing regression tests for tables and even for blocks
(block/printing). 

They run only under windows.

You can start them either via
http://lxr.mozilla.org/seamonkey/source/layout/html/tests/table/printing/rtest.bat

or by renaming file_list.txt into file_list_printing.txt (rename means do not
keep a file_list.txt file in that directory)

http://lxr.mozilla.org/seamonkey/source/layout/html/tests/block/runtests.sh#97

and running the usual rtest.sh. 

Your default printer driver should not default to print to a file.

And probably in the mean time somebody already horked those tests again with
some stupid dialog, you will need to find how to disable it.
Flags: blocking1.3? → blocking1.3-
Attached patch Patch v0.9 — — Splinter Review 
This patch does the trick, but there is another crash in there (in frame
destruction) that happens after print preview; unsure if it's related yet.

What this does is make it so that we set the proper row as the last row on the
page if there was another row frame.  For whatever reason (I can't think of
any) even though we wanted to split the next frame, we were pretending like we
didn't want to put any of it on the page in question.
Not that familiar with the release cycle and what gets in when etc, but is this
bug fix likely to make it into 1.3.1 or will it have to wait for 1.4?  I only
ask as a few people in my organisation have to print pages from the Austrailan
Tax Office (which the above url is from) and numerous of the pages cause this
problem which is very frustrating for them.  My organisation prefers to use
final releases, so I'm wondering if I'll only be in for a little wait (for
1.3.1) or a longer wait (for 1.4 final).

Not sure if anyone can give me any idea, and sorry if this is not really the
place to ask such questions but I couldn't find anywhere to give me an idea as
to the process.

cheers,

noel
It seems unlikely to make 1.3.1, but I'll ask anyway.
Attached patch Patch — — Splinter Review 
OK, after a long, helpful talk with Karnaze, this one feels much more righter. 
I will run the printing regression tests.

The problem, simply put, was that we were running the loop through *all* frames
instead of up through aLastFrame.  Since we weren't even supposed to put the
second row frame on the first page, we certainly shouldn't have tried to split
cells onto it.	Basically if you go past aLastFrame you can still find cells
with rowspans that extend past the end of the page.  In fact, you are
guaranteed that the first cell with a rowspan will be a problem.  Then all hell
breaks loose.
Comment on attachment 117792 [details] [diff] [review]
Patch

Chris, this is the patch we talked about on the phone a couple of weeks ago. 
Finally with Bernd's help I got the printing regression tests working, and
there are no  true positives.
Attachment #117792 - Flags: review?(karnaze)
Comment on attachment 117792 [details] [diff] [review]
Patch

why not isLast or isLastRow?
Attachment #117792 - Flags: review?(karnaze) → review+
Comment on attachment 117792 [details] [diff] [review]
Patch

Because it's asking whether the row we used on the *previous* iteration is the
last row, not the current iteration.
Attachment #117792 - Flags: superreview?(kin)
Comment on attachment 117792 [details] [diff] [review]
Patch

sr=kin@netscape.com

Looks ok to me, but should we be checking for a null |row| like the original
|for| expression did? That is, should we be checking for |row && !wasLast|? Or
are we guaranteed that |aFirstRow| and |aLastRow| will never be null?

-  for (nsTableRowFrame* row = &aFirstRow; row; row = row->GetNextRow()) {
+  for (nsTableRowFrame* row = &aFirstRow; !wasLast; row = row->GetNextRow()) {
Attachment #117792 - Flags: superreview?(kin) → superreview+
http://bugzilla.mozilla.org/attachment.cgi?id=124837&action=view

the testcase here includes a div element, the link above does not, and can be
prevented three different ways, is this part of this bug or should a separate
report be filed on this?
Fix checked in yesterday.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: