Closed Bug 194330 Opened 22 years ago Closed 22 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: 22 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: