Print preview crashes the browser [@ nsGfxScrollFrame::Destroy ]




Print Preview
15 years ago
15 years ago


(Reporter: George Credland, Assigned: roc)


({crash, testcase})

crash, testcase
Bug Flags:
blocking1.3 -

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [adt2][fix], crash signature, URL)


(7 attachments, 1 obsolete attachment)



15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210

(This has validated with as valid HTML 4.01 Strict)

When I try to Print Preview on this page, the browser crashes.

Reproducible: Always

Steps to Reproduce:
1. Open URL
2. Print Preview from the menu.

Actual Results:  
Browser crashes.

Expected Results:  
Shown Print Preview.

No additional information displayed.

I can "Print Preview" on other pages without incident.

Print Preview works fine in Netscape 7.01 for the problem page.

Comment 1

15 years ago
Works fine on Linux with mozilla cvs 20030217, both Print Prieview and
actual Printing. Must be Windoze specific.

Comment 2

15 years ago
Reporter, for me it crashes on clicking close in print preview -- is that the same
for you or does it crash on entering print preview? Do you have a talkback 
incident number?

2003021623 Solaris/SPARC

Possibly related to any of: bug 190257, bug 163800, bug 156982, bug 152536

Comment 3

15 years ago
To confirm. Browser crashes immediately on selecting "Print Preview" from the
menu on Windows 2000 and XP Professional. I don't get the print preview window.

Comment 4

15 years ago
confirming for the moment - may be a dupe, need the stack. TB17262060G
Severity: normal → critical
Ever confirmed: true
Keywords: crash, stackwanted
Whiteboard: TB17262060G

Comment 5

15 years ago
Created attachment 114684 [details]
DrWatson crash log

Crash created on closing Print Preview window.

Comment 6

15 years ago
Just uploaded the DrWatson log for a crash on closing Print Preview window.
(Matches report from Piers Cornwell)

It was produced using Windows XP Professional (Service Pack 1).

Interestingly, it let me see the Print Preview window, whereas previously the
crash occurred on opening the window. However, much of the page contents were
not rendered e.g. Labels, Fieldset frame and legend, buttons, images for buttons
at bottom of page.

Comment 7

15 years ago
Yeah, the crash on exit is at:

#0 0x7f3458e8 in nsVoidArray virtual table ()
from /Moz/mozilla/./
#1 0x7dd59be0 in NSGetModule ()
from /Moz/mozilla/components/

which i think is known already.

Comment 8

15 years ago
Btw, i'm on Win2000 now (20030216) and i get the same as you: it sometimes crashes
on entering print preview and sometimes not. Lets keep this bug just for that 
issue since the crash on exit is a different problem and the lack of display of 
form elements is bug 192938.

Comment 9

15 years ago
confirming with

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030214

Comment 10

15 years ago
Confirming it with build 2003021008 under Windows XP SP1.

Talkback ID: TB17270691K

Comment 11

15 years ago
WFM 0215 WinXP trunk

Comment 12

15 years ago
Created attachment 114771 [details]
DrWatson crash log on entering Print Preview (Windows2000 SP3)

DrWatson crash log on entering Print Preview (Windows2000 SP3)


15 years ago
Flags: blocking1.3?


15 years ago
Keywords: stackwanted
OS: Windows 2000 → All
Hardware: PC → All
Summary: Print preview crashes the browser (with the supplied URL) → Print preview crashes the browser [@ nsGfxScrollFrame::Destroy ]
Whiteboard: TB17262060G

Comment 13

15 years ago
Created attachment 115308 [details]
Stack trace Linux 20030223


15 years ago
Flags: blocking1.3? → blocking1.3-

Comment 15

15 years ago
*** Bug 195198 has been marked as a duplicate of this bug. ***
I can't always reproduce the crash, but if I adjust the Print Preview size
settings it usually happens sooner or later.

Sometimes, even without crashing, I see

###!!! ASSERTION: unexpected frame type: 'PR_FALSE', file c:/MozillaWork/shaping
1/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp, line 11645

with frameType "FieldSetFrame", followed by one or two

###!!! ASSERTION: reflow dirty lines failed: 'NS_SUCCEEDED(rv)', file c:/Mozilla
Work/shaping1/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 942

When I do crash, it is in nsGfxScrollFrameInner::GetScrollableView, with view
not null but containing lots of 0xfeeefeee
Need a minimized test case. Can someone cut the page down to the minimum HTML
needed to provoke the crash?

Comment 18

15 years ago
Created attachment 115987 [details]
not-minimal testcase

well I had a go at a testcase, but I'm afraid after 30 minutes of messing
around, I can't figure it out. Page is a mass of nested tables - chopping even
a cell out of the mess makes it work... maybe someone can improve on this.

Comment 19

15 years ago
Created attachment 116009 [details]

seems to need an <input> in the second page of a <fieldset>.


15 years ago
Keywords: testcase

Comment 20

15 years ago
Created attachment 116010 [details]
fun with valgrind

Comment 21

15 years ago
I should add that Mozilla crashes when closing print preview of the testcase. 
Getting a testcase for crashing when opening print preview was futile and the
crash-on-close is also in nsGfxScrollFrame::Destroy.
*** Bug 197808 has been marked as a duplicate of this bug. ***

Comment 23

15 years ago
Duplicate bug 197808 claims crash on opening print preview happens if forms are
longer than one page.

Comment 24

15 years ago
I'm not sure if this is related (I was about to file a bug but found this one
which seems to be close) but Print Preview crashes for me on this article about
This page has special CSS specifically for print media.  I'm using 1.3 final on
i can easily crash this when i bring up Print Preview for the bugzilla query page,

this occurred on both win2k and linux rh8.0 (2003.05.28-1.4 builds).

talkback reports:

if what i'm seeing is a different issue, let me know and i'll file another bug.
Flags: blocking1.4?
Keywords: nsbeta1
QA Contact: sujay → sairuh

Comment 26

15 years ago
this is probably related to bug 156982 (based on valgrind log)

Comment 27

15 years ago
adt: nsbeta1+/adt2
Assignee: rods → kmcclusk
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2]
-> jkeiser
Assignee: kmcclusk → jkeiser
Assignee: jkeiser → roc+moz
Priority: -- → P2
Created attachment 124621 [details] [diff] [review]

The problem is that frames in the overflowList of an nsContainerFrame or
nsBlockFrame were not being destroyed until the PresShell was torn down. By
that time, their views had already been destroyed (because when we destroy a
view, we also destroy its children), so we tried to destroy the views again ...

The right thing to do is to delete overflow child frames when we delete the
parent frame.

nsContainerFrame also needs to report the overflowList as a possible source of
child frames.
Created attachment 124632 [details] [diff] [review]
correct patch

That patch was missing a file. This is the right patch.
Attachment #124621 - Attachment is obsolete: true
Whiteboard: [adt2] → [adt2][fix]
Attachment #124632 - Flags: superreview?(dbaron)
Attachment #124632 - Flags: review?(dbaron)
Comment on attachment 124632 [details] [diff] [review]
correct patch

I guess the original intent here was that the overflow lists be temporaries
during reflow that never survive past the end of the reflow, so they wouldn't
need to be reported this way.  I'd think that ought to be happening, though. 
Any idea why it isn't?

>+nsContainerFrame::GetAdditionalChildListName(PRInt32   aIndex,
>+                                             nsIAtom** aListName) const
>+  NS_PRECONDITION(nsnull != aListName, "null OUT parameter pointer");
>+  if (aIndex < 0) {
>+    return NS_ERROR_INVALID_ARG;
>+  }

How about something that asserts, since you're not filling in the out param?
is a possibility.

Attachment #124632 - Flags: superreview?(dbaron)
Attachment #124632 - Flags: superreview+
Attachment #124632 - Flags: review?(dbaron)
Attachment #124632 - Flags: review+
I think the situation here is that the fieldset can't be split across pages, so
the overflow lines belonging to its block survive the end of reflow, because
there's no next in flow block to take them.

Also, it is important to return the full set of child lists even during reflow,
for example, when a frame is reparented and we need to reparent the views of all
children including any overflow children. I fixed a bug like that a while ago by
making nsBlockFrame report its overflowList.

> How about something that asserts

Sure, I'll do that.
Comment on attachment 124632 [details] [diff] [review]
correct patch

this is a fairly straightfoward fix for a crasher. I wouldn't say it blocks 1.4
but it would be nice to get it in. If there's time I'd like to let the fix bake
on the trunk for a couple of days before landing this into 1.4.
Attachment #124632 - Flags: approval1.4?
Checked into trunk.
This seems to have caused about a 1% Tp hit on Linux only. Gaaah
Comment on attachment 124632 [details] [diff] [review]
correct patch

Please add fixed1.4 when checked into the branch.
Attachment #124632 - Flags: approval1.4? → approval1.4+

Comment 38

15 years ago
I came across this myself.  I can upload my test case (not 100% minimal, but
fairly so) if desired.  I'm using 1.4RC1 on Windows XP SP 1  (Build ID:

Crash on exit of print preview (or when trying to switch to Landscape mode,
etc.)  The print preview itself doesn't come up.

Glad to know it looks like y'all have it nailed down.
checked into branch.
Last Resolved: 15 years ago
Flags: blocking1.4?
Keywords: fixed1.4
Resolution: --- → FIXED
vrfy'd fixed using comm 2003.06.06.08-trunk and 2003.06.06.13-1.4 builds on
linux rh7.2. tested on the bugzilla query page and the other test pages
mentioned here.
Keywords: fixed1.4 → verified1.4
Crash Signature: [@ nsGfxScrollFrame::Destroy ]
You need to log in before you can comment on or make changes to this bug.