156982 - close button in print preview crashes [@ nsContainerFrame::Destroy]

Status: VERIFIED WORKSFORME

(Core :: Web Painting, defect, P2)

Description

[Tuukka Tolvanen (sp3000)]

Found this while testing for bug 156965, stack and timing are different.

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a+) Gecko/20020711
BuildID:    trunk cvs 2002-07-11

1) load http://www.fileplanet.com/index.asp
2) file>print preview
3) hit 'close'
-> crashes.

Reproducible: Always

Comment 1

[Tuukka Tolvanen (sp3000)]

Attachment: debug build assertions and gdb bt

Comment 2

[Tuukka Tolvanen (sp3000)]

************************************************************
* Call to xpconnect wrapped JSObject produced this error:  *
[Exception... "'[JavaScript Error: "rogressParams is not defined" {file:
"chrome://global/content/printPreviewProgress.js" line: 79}]' when calling
method: [nsIWebProgressListener::onProgressChange]"  nsresult: "0x80570021
(NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)"  location: "JS frame ::
chrome://navigator/content/browser.js :: FinishPrintPreview :: line 284"  data: yes]
************************************************************

{~/src/mozilla/mozilla}$ egrep -r --line-number "[^[:alpha:]]rogressParams" .
./xpfe/global/resources/content/printPreviewProgress.js:79:        var docURLStr
= elipseString(rogressParams.docURL, true);

Comment 3

[Tuukka Tolvanen (sp3000)]

fixing the typo (comment 2) doesn't fix the crash -> spun off to bug 156984

Comment 4

[greer]

Attachment: Stacks

WFM with N7.0PR1. However, I was able to crash a couple of Mozilla builds
(attached) with rather different stacktraces.

Comment 5

[kinmoz]

The first stack trace reported in greer's stacks atachment 91024 matches the one
in bug 138349, see that bug for details on why it's happening.

Comment 6

[rods (gone)]

--> over to core layout

Comment 7

[Andrew Schultz]

current CVS is crashing just opening Print Preview.  Some different assertions:
###!!! ASSERTION: no prev in flow: 'PR_FALSE', file nsBlockFrame.cpp, line 5516
(a whole lot of that one)
###!!! ASSERTION: bad geometric parent: '(childState & NS_FRAME_OUT_OF_FLOW) ||
IsChild(aPresContext, aChild)', file nsBlockFrame.cpp, line 5288
###!!! ASSERTION: no prev in flow: 'PR_FALSE', file nsBlockFrame.cpp, line 5516
4 of those (no prev in flow)
###!!! ASSERTION: bad geometric parent: '(childState & NS_FRAME_OUT_OF_FLOW) ||
IsChild(aPresContext, aChild)', file nsBlockFrame.cpp, line 5288
###!!! ASSERTION: no prev in flow: 'PR_FALSE', file nsBlockFrame.cpp, line 5516
4 more of those (no prev in flow)
###!!! ASSERTION: bad push: 'overBegin != begin_lines()', file nsBlockFrame.cpp,
line 4569
###!!! ASSERTION: running past end: 'mCurrent != mListLink', file nsLineBox.h,
line 537
(crash)

Comment 8

[Andrew Schultz]

Attachment: testcase

this crashes linux trunk build 20020728 and CVS when opening print preview. 
the stack is similar to the first one in greer's attachment
(nsContainerFrame::Destroy).  Debug build does not throw any assertions.

if you remove almost anything from the testcase (even the action attribute on
the form), it will not crash when opening print preview or closing it.

Comment 9

[Louie Zhao]

mozilla crash when just open "print preview" with the trunk(2002-8-6)
But "http://www.fileplanet.com/index.asp" can be previewed on mozilla1.0, and
browser won't crash when close preview dialog.

There is another testcase which can cause mozilla1.0 crash when close print
preview dialog.It's 
resource:///res/samples/test12.html

Comment 10

[Andrew Schultz]

URL crashes with trunk build 2002052908 but not 2002052808
testcase crashes with trunk build 2002071708 but not 2002071522
current 1.0 branch builds do not crash on URL or testcase

Comment 11

[Andrew Schultz]

Attachment: valgrind log opening print preview with the testcase

using valgrind (http://developer.kde.org/~sewardj/) to open the testcase in
print preview, it identifies these problems.  Basically, it appears to be
trying to double-free an nsView.

Comment 12

[Pete Zha]

Attachment: test case for comment 9

test case for comment 9

Comment 13

[Pete Zha]

Attachment: patch to avoid crash for attachment 94901

This patch could avoid crash for attachment 94901 [details] in comment 12. But can't
resolve the preview display problem for that page. That problem is because
print preview doesn't support CSS2 style. Should be another bug I think.

Comment 14

[Pete Zha]

taking

Comment 15

[Andrew Schultz]

Comment on attachment 95082 [details] [diff] [review]
patch to avoid crash for attachment 94901 [details]

this patch does not fix this bug.  it does not fix the URL or the testcase.  it
seems that the crash with attachment 94901 [details] is not related to this bug.

Comment 16

[Pete Zha]

Seems like the original problem of this bug has been fixed.
The crash of attachment 94901 [details] must be another bug. Let me check and file.

Comment 17

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 95082 [details] [diff] [review]
patch to avoid crash for attachment 94901 [details]

So.... 

1)  What actually triggers the crash if we have neither scrollbar?

and

2)  Why do we have neither scrollbar?

Comment 18

[Pete Zha]

I'm investagating it. It's tough...

Comment 19

[Andrew Schultz]

I don't know how relevant it is here, but see bug 161834 for some funny-business
with mHas(Horizontal/Vertical)Scrollbar.

It might be that one of those is erroneously set to "true" (something other than
0).  You might check the actual value to see if it's 0, 1, or something random.

Comment 20

[Pete Zha]

The reason is the <DIV> with position:fixed attribute can not be shown on
preview page. So, the scroll frame be destroied without remove it's mInner from
document's observers list.
Who has idea how to fix the fixed problem in print preview?

Comment 21

[rods (gone)]

Comment on attachment 95082 [details] [diff] [review]
patch to avoid crash for attachment 94901 [details]

r=rods

Comment 22

[rods (gone)]

Comment on attachment 95082 [details] [diff] [review]
patch to avoid crash for attachment 94901 [details]

never mind on the r=rods, problems with "fixed" are known but have been low
priority since very few sites use it.

Comment 23

[Pete Zha]

Attachment: patch with Andrew Schultz's comments

Add a fix for comment 19.

Comment 24

[rods (gone)]

So does the patch stop the PP crash?

Comment 25

[Andrew Schultz]

Comment on attachment 95959 [details] [diff] [review]
patch with Andrew Schultz's comments

wouldn't it be better to set aHasScrollbar to PR_FALSE within
AddRemoveScrollbar?

Comment 26

[Pete Zha]

>So does the patch stop the PP crash?
You mean the print preview crash?
Yes, it stops the crash in attachment 94901 [details]

>wouldn't it be better to set aHasScrollbar to PR_FALSE within
>AddRemoveScrollbar?
Yes, maybe it's better. a new patch iscoming

Comment 27

[Pete Zha]

Attachment: patch (add "aHasScrollbar = PR_FALSE;" at the end of AddRemoveScrollbar)

Comment 28

[Andrew Schultz]

I was going to test the patch, but attachment 94901 [details] does not crash any of my
linux builds (current trunk, 1.1b, 1.0 or 1.0rc1).

Comment 29

[Andrew Schultz]

I do crash with attachment 94901 [details] if I just add "aHasScrollbar=PR_FALSE;"
the check you added does then prevent the crash.

Comment 30

[Pete Zha]

>I was going to test the patch, but attachment 94901 [details] does not crash any of my
>linux builds (current trunk, 1.1b, 1.0 or 1.0rc1).
Please make sure the window small enough that you can see the scrollbar of the
fixed DIV.

Comment 31

[Andrew Schultz]

> Please make sure the window small enough that you can see the scrollbar of the 
> fixed DIV.

that was it.  Now I see the crash.

Comment 32

[rods (gone)]

The "fileplanet" site is only using relative and absolute positioning. It would
be very helpful if someone could reduce it down to a simplier testcase. 

I threw together a simple relative/abs example and it preinted fine. I think it
is really unclear as to how a "fixed" positioned element should print, because
it is fixed to the "viewport" what is a "viewport" when printing. Also, does the
CSS spec say anothing about printing and fixed positioned elements?

IE 6.x doesn't even support fixed position. I think we need to figure out why
the rel/abs example doesn't work.

Comment 33

[Andrew Schultz]

> The "fileplanet" site is only using relative and absolute positioning. It would
> be very helpful if someone could reduce it down to a simplier testcase. 

that would be attachment attachment 93248 [details] (the third attachment here)

Comment 34

[Andrew Schultz]

note that no element in the fileplanet testcase is fixed or absolute.

Comment 35

[rods (gone)]

The reduced testcase (attachment #3 [details] [diff] [review]) doesn't crash on Win2k with the last patch
applied, but the original site still crashes. So I am hoping there is a
different reduced testcase that will crash on Win2k.

Comment 36

[Andrew Schultz]

I think there are definitely multiple problems with the fileplanet page under
Linux.  The patch apparently fixes one of them, which might be the only one
under Windows.  On Linux, the first patch did not fix the testcase or the URL (I
didn't try out the most recent patch).

I tried tracking down what caused the regression, but (on Linux), the testcase
regressed at a different time than the URL.  see comment 10.

Comment 37

[Andrew Schultz]

the latest patch does not help on Linux for fileplanet testcase or URL.

Comment 38

[Pete Zha]

Yes, there are lots of problem here. I tested trunk build(Mozilla/5.0 (Windows;
U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020820) and got this result:
1)URL: crash when preview
2)testcase (attachment 932488) doesn't crash at preview and close preview
3)testcase for comment 9 (attachment 94091 [details]) crash when close preview.

My last patch can fix the 3th problem.

Comment 39

[Pete Zha]

The problem of attachment 94901 [details] will be fixed in a separate bug.(bug 163800)

Comment 40

[Boris Zbarsky [:bzbarsky]]

> Also, does the CSS spec say anothing about printing and fixed positioned
> elements?

From http://www.w3.org/TR/REC-CSS2/visuren.html#propdef-position:

  In the case of paged media, the box is fixed with respect to the page, even if
  that page is seen through a viewport (in the case of a print-preview, for
  example)

In other words, any position:fixed element should appear on all pages when
printing, with the top/left/right/bottom offsets measured from the page content
edge.

Now that bug 163800 is fixed, what is left to do here?

Comment 41

[Andrew Schultz]

> what is left to do here?

stop double-freeing an nsView (comment 11)
the behavior of attachment 93248 [details] has not changed on Linux.

Comment 42

[Simon Paquet [:sipaq]]

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

Comment 43

[timeless]

roc :)

Comment 44

[timeless]

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

Comment 45

[Matthias Versen [:Matti]]

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

Comment 46

[alanjstr]

This bug causes http://www.dto.tudelft.nl/ to crash 1.3 just by visiting it.  
See Bug 194631 for more details.

Comment 47

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

I retested all these on a new build and everything works --- except for the
original crasher, print preview on http://www.fileplanet.com/index.asp! Can
someone please confirm this? If this is correct, then we need a new reduced
testcase for fileplanet. Thanks in advance...

Comment 48

[Andrew Schultz]

Attachment: another testcase

testcase crashes with linux trunk 2003041508

Comment 49

[Andrew Schultz]

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

Comment 50

[Jay Patel [:jay]]

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

Comment 51

[Jay Patel [:jay]]

Yes, closing print preview is still crashing.  Here is a recent incident:

Incident ID 20041191
Stack Signature 	0x0000009b 68744419
Email Address 	[e-mail]
Product ID 	MozillaTrunk
Build ID 	2003051214
Trigger Time 	2003-05-13 02:21:42
Platform 	Win32
Operating System 	Windows NT 5.0 build 2195
Module 	
URL visited 	
User Comments 	
Trigger Reason 	Access violation
Source File Name 	
Trigger Line No. 	
Stack Trace 	
0x0000009b
nsContainerFrame::Destroy
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 140]
ViewportFrame::Destroy
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsViewportFrame.cpp, line 68]
nsLineBox::DeleteLineList
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsLineBox.cpp, line 307]
nsBlockFrame::Destroy
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 425]
nsFrameList::DestroyFrames
[c:/builds/seamonkey/mozilla/layout/base/src/nsFrameList.cpp, line 131]
nsContainerFrame::Destroy
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 143]
nsFrameList::DestroyFrames
[c:/builds/seamonkey/mozilla/layout/base/src/nsFrameList.cpp, line 131]
nsContainerFrame::Destroy
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 143]
nsFrameList::DestroyFrames
[c:/builds/seamonkey/mozilla/layout/base/src/nsFrameList.cpp, line 131]
nsContainerFrame::Destroy
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 143]
nsFrameList::DestroyFrames
[c:/builds/seamonkey/mozilla/layout/base/src/nsFrameList.cpp, line 131]
nsContainerFrame::Destroy
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 143]
nsTableFrame::Destroy
[c:/builds/seamonkey/mozilla/layout/html/table/src/nsTableFrame.cpp, line 312]
nsFrameList::DestroyFrames
[c:/builds/seamonkey/mozilla/layout/base/src/nsFrameList.cpp, line 131]
nsContainerFrame::Destroy
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 143]
nsTableOuterFrame::Destroy
[c:/builds/seamonkey/mozilla/layout/html/table/src/nsTableOuterFrame.cpp, line 83]
nsLineBox::DeleteLineList
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsLineBox.cpp, line 307]
nsBlockFrame::Destroy
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 425]
nsLineBox::DeleteLineList
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsLineBox.cpp, line 307]
nsBlockFrame::Destroy
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 425]
nsFrameList::DestroyFrames
[c:/builds/seamonkey/mozilla/layout/base/src/nsFrameList.cpp, line 131]
nsContainerFrame::Destroy
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 143]
ViewportFrame::Destroy
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsViewportFrame.cpp, line 68]
nsFrameList::DestroyFrames
[c:/builds/seamonkey/mozilla/layout/base/src/nsFrameList.cpp, line 131]
nsContainerFrame::Destroy
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 143]
nsFrameList::DestroyFrames
[c:/builds/seamonkey/mozilla/layout/base/src/nsFrameList.cpp, line 131]
nsContainerFrame::Destroy
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 143]
nsFrameList::DestroyFrames
[c:/builds/seamonkey/mozilla/layout/base/src/nsFrameList.cpp, line 131]
nsContainerFrame::Destroy
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 143]
nsBoxFrame::Destroy
[c:/builds/seamonkey/mozilla/layout/xul/base/src/nsBoxFrame.cpp, line 1104]
nsFrameList::DestroyFrames
[c:/builds/seamonkey/mozilla/layout/base/src/nsFrameList.cpp, line 131]
nsContainerFrame::Destroy
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 143]
nsBoxFrame::Destroy
[c:/builds/seamonkey/mozilla/layout/xul/base/src/nsBoxFrame.cpp, line 1104]
nsGfxScrollFrame::Destroy
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsGfxScrollFrame.cpp, line 460]
nsFrameList::DestroyFrames
[c:/builds/seamonkey/mozilla/layout/base/src/nsFrameList.cpp, line 131]
nsContainerFrame::Destroy
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 143]
ViewportFrame::Destroy
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsViewportFrame.cpp, line 68]
FrameManager::Destroy
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsFrameManager.cpp, line 517]
PresShell::Destroy
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 1843]
DocumentViewerImpl::InstallNewPresentation
[c:/builds/seamonkey/mozilla/content/base/src/nsDocumentViewer.cpp, line 3747]
nsPrintEngine::FinishPrintPreview
[c:/builds/seamonkey/mozilla/content/base/src/nsPrintEngine.cpp, line 4551]
nsPrintEngine::PrintPreview
[c:/builds/seamonkey/mozilla/content/base/src/nsPrintEngine.cpp, line 1272]
DocumentViewerImpl::PrintPreview
[c:/builds/seamonkey/mozilla/content/base/src/nsDocumentViewer.cpp, line 3139]
XPTC_InvokeByIndex
[c:/builds/seamonkey/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp,
line 102]
XPCWrappedNative::CallMethod
[c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2025]
XPC_WN_CallMethod
[c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1285]
js_Invoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 845]
js_Interpret [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 2853]
js_Invoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 861]
nsXPCWrappedJSClass::CallMethod
[c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 1334]
nsXPCWrappedJS::CallMethod
[c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 429]
PrepareAndDispatch
[c:/builds/seamonkey/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp,
line 119]
SharedStub
[c:/builds/seamonkey/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp,
line 147]
nsPrintProgress::DoneIniting
[c:/builds/seamonkey/mozilla/embedding/components/printingui/src/win/nsPrintProgress.cpp,
line 228]
XPTC_InvokeByIndex
[c:/builds/seamonkey/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp,
line 102]
XPCWrappedNative::CallMethod
[c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2025]
XPC_WN_CallMethod
[c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1285]
js_Invoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 845]
js_Interpret [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 2853]
js_Invoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 861]
js_InternalInvoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 936]
JS_CallFunctionValue [c:/builds/seamonkey/mozilla/js/src/jsapi.c, line 3529]
nsJSContext::CallEventHandler
[c:/builds/seamonkey/mozilla/dom/src/base/nsJSEnvironment.cpp, line 1082]

I just marked bug 205478 a dup...the stack above is from there.

Comment 52

[Matthias Versen [:Matti]]

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

Comment 53

[Matthias Versen [:Matti]]

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

Comment 54

[Matthias Versen [:Matti]]

The URL from Bug 206156 crashes in todays win2k build (crash in the browser and
not in print preview or while printing)

Comment 55

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

Matti, why did you mark 206156 a duplicate of this?

Comment 56

[Matthias Versen [:Matti]]

because I compared the top of the stacks in both bugs ?
Sorry if i did a mistake with the duping...

Comment 57

[Matthias Versen [:Matti]]

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

Comment 58

[Zook Valem]

Attachment: Another Test Case for couple of Print Preview's features

Here is another testcase that cause the Mozilla crash on 'Scale' Selection menu
bar, 'Landscape/Portrait' Button and 'Close' Button.  Any one of those three
features cause a top crash in Mozilla.	For some reason, When I remove any one
of those HTML tags such as DIV, P, <br>, etc...  It no longer crash Mozilla. 
This testcase come from a duplicate of bug# 207098.  More testcases is good,
better than one testcase only.

Comment 59

[Zook Valem]

Can anyone update the summary to include the 'Scale' Select-Option Bar and
'Portrait/Landscape' Menu bar which bug# 207098 is a duplicate of this bug?  I
don't have the permission for that.

Comment 60

[John Keiser (jkeiser)]

I am not seeing this in Firebird 20030529, BTW.

Comment 61

[Andrew Schultz]

the URL hangs both Mozilla and Firebird 20030529.  the testcase (attachment
120673 [details]) works in both.

attachment 124233 [details] also induces the crash.

Comment 62

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

Attachment: testcase

None of these testcases work for me anymore, but fileplanet.com still crashes.
This testcase is reduced from the fileplanet page and it DOES work for me as of
today.

Comment 63

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

by 'work' I mean 'crash'

Comment 64

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

Attachment: better testcase

Better testcase.

Here's roughly what happens:
-- the frame for "featuredmod" is relatively positioned, so has a view.
Furthermore it spans the page boundary so its continuation also has a view.
-- the view for the relatively-positioned last "dailydlimg" is not correctly
reparented from the first "featuredmod" view to the view for the continuation.
That is why we crash.

What I have to figure out is why the view for "dailydlimg" is not being
reparented when that frame is pushed to the second page.

Comment 65

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

Attachment: even better

This reduces things even further by eliminating the wrapper DIVs that were
present before.

"dailydlimg" is a relatively positioned float which appears to get split.
hmmmmm

Comment 66

[Peter Kroll]

chrome://global/content/MPL-1.1.html

Mozilla crashes on this url as well. When I click close on the print preview
button. Also print preview only shows 2 pages, when there should be more. Not
sure if that's a new bug or related.

Mozilla 1.4b

In my opinion this is a blocker bug. I was typing a long email when Mozilla
crashed. Any always reproducible bug on such a common feature is a blocker.
Please do not release 1.4 with this bug.

Comment 67

[Zook Valem]

Hey Folks!

Just saw the bug fix on bug #212821.  That bug is not related to this one but it
spoke of print preview that show only one page in print preview while there is
actually more than 1 pages.  I will have to re-read that bug just a few more
times to find out what that bug is really about. 

For now, I wonder if that bug fix might help to ease the aggrivated situation on
this existing bug we have.  So, can you all folks try out the newer build and
see if this situation remain unchanged or just got a bit easier?  Something that
might will bring in some changes that we haven't see before?  It should be
interesting to find out what have changed or not.  I can't download the latest
build for a while.  Thanks!

Comment 68

[Martijn Wargers (dead)]

Used the nightly build, and it still crashes.
Using:Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030908
Firebird/0.6.1+

I have also made some -I think- related testcases.
http://home.hccnet.nl/m.wargers/test/mozilla/crash/print/
The first one in this directory crashes immediately in print preview.
Te second one by closing the print preview.
In the second testcase I have onley removed this style-rule:
.groep{
background-color:#66cccc;
width:950px;
}
To reproduce the crash:
-you have to use the 'shrink to fit' scale option in print preview.
-The test-case has to span more than one page.
-I have to use boxes with float:left; position:relative;

Comment 69

[Adam Hauner]

Attachment: Martijn's testcase 1 (crash on Print Preview)

Comment 70

[Adam Hauner]

Attachment: Martijn's testcase 2 (crash on Print Preview close)

Comment 71

[Adam Hauner]

2003090809/trunk/W2K is crashing on "Martijn's testcase 1" (-> TB23454385Y),
"Martijn's testcase 2" (-> TB23454454H) and "even better" testcase (->
TB23454698M). All other testcases WFM.

Comment 72

[Adam Hauner]

Attachment: Stacks for both Martijn's testcases (on W2K)

Comment 73

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: talkback stacks from comment 71

Comment 74

[timeless]

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

Comment 75

[Zook Valem]

You can't just block the Mozilla 1.6 release without a working patch.  I have
seen it all too often on other bugs which Asa commented that bug can't be
blocked without a working patch.

Comment 76

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

That's not a requirement.  However, we're unlikely to hold for bugs that we've
shipped with before.

Comment 77

[chris hofmann]

renominate if we get close to a fix for 1.6

Comment 78

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 02/17 - 02/21)]

Still confirmable with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a3)
Gecko/20040723 Firefox/0.9.1+. 

Comment 79

[John Benes]

still confirmable with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; 
rv:1.7.3) Gecko/20041026 Firefox/1.0RC1
Talkback incident: TB1626150Q

Comment 80

[Stephen Donner [:stephend] Not actively reading bugmail]

With a current trunk build: 2004-12-03-04, I don't crash on neither any of the
testcases listed in this bug, nor the site of www.fileplanet.com

Comment 81

[Adam Hauner]

Stephen, in comment #66 is repro (chrome://global/content/MPL-1.1.html -> Print
Preview -> close), which is still crashing for me with 2004112306/SM-trunk/W2k.
Unfortunatelly, I'm unable to submit Talkback incident ID. Could you retry it?

Previously crashing "Martijn's testcase 1", "Martijn's testcase 2" and "even
better" testcases are WFM with same build.

Comment 82

[Stephen Donner [:stephend] Not actively reading bugmail]

Adam, chrome printing/print-preview bugs are covered in bugs such as bug 218304,
and are known to still crash on the trunk.

Comment 83

[Adam Hauner]

Stephen, all attached testcases and FilePlanet title page are WFM in
2004120304/SM-trunk/W2K. I'll fill bug for MPL issue.

Could anybody try it on Linux, so we could mark it as WFM?

Comment 84

[Tuukka Tolvanen (sp3000)]

With seamonkey trunk linux gtk2+xft 20041204 I crash at step 2 of comment 0 [@
nsLineBox::IsEmpty], so I can't really test this one...

Comment 85

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 02/17 - 02/21)]

Jay, this bug still exists on branch builds of Firefox. Seems that there is a
patch which isn't currently checked into the trunk?

-> REOPEN

Comment 86

[Christian Franke]

Possibly related/dup printing problems using the URL from comment 0:
Bug 273363 preview formatting out of bounds on Win2K
Bug 278868 crash on print+preview on Win98SE

Comment 87

[Martijn Wargers (dead)]

All the testcase don't crash for me on print preview, as far as I can tell, in
the 2005-02-23 build (part of them already might have worked before the fix of
bug 263825).
However, the url crashes for me now on print preview. Talkback ID: TB4557724M
The stack of that leads to bug 262403. A fix for that bug is already there and
will probably be checked in soon.

Comment 88

[Martijn Wargers (dead)]

Ok, doesn't crash anymore in 20050324 build. Most likely fixed by the fix for
bug 262403.

Comment 89

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 02/17 - 02/21)]

v. (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050405 Firefox/1.0+)