Closed Bug 54004 Opened 24 years ago Closed 24 years ago

Crashes while printing page [@nsWindow::Create]

Categories

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

Product:
Core
Component:
Printing: Output
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: rods, Assigned: dcone)

References

(
URL
)

Details

(Keywords: crash, topcrash, Whiteboard: [rtm-])

Crash Data

Attachments

(1 file)

zip file containing src that will crash when printing to PS file
1.53 KB, application/octet-stream
Details 
If I load the URL above and then print the page as soon as possible it crashes 
(I add stack trace soon). If I wait for 30 seconds to a minute, then it prints 
fine.
This does not crash in printing.. this crashes in the notifications while 
loading all the URL's.  I think this is a Necko problem...
This is the Stack trace I got... 




NTDLL! 77f7629c()
nsWindow::Create(nsWindow * const 0x032074a4, nsIWidget * 0x00000000, const 
nsRect & {...}, nsEventStatus (nsGUIEvent *)* 0x024b39f4 HandleEvent(nsGUIEvent 
*), nsIDeviceContext * 0x03230f60, nsIAppShell * 0x00000000, nsIToolkit * 
0x00000000, nsWidgetInitData * 0x00000000) line 1081
nsView::CreateWidget(nsView * const 0x032075e0, const nsID & {...}, 
nsWidgetInitData * 0x00000000, void * 0x00000000, int 1) line 965
DocumentViewerImpl::MakeWindow(nsIWidget * 0x035b6a34, const nsRect & {...}) 
line 1173 + 47 bytes
DocumentViewerImpl::Init(DocumentViewerImpl * const 0x031d6900, nsIWidget * 
0x035b6a34, nsIDeviceContext * 0x03230f60, const nsRect & {...}) line 537 + 16 
bytes
nsDocShell::SetupNewViewer(nsDocShell * const 0x035b5730, nsIContentViewer * 
0x031d6900) line 2775 + 66 bytes
nsWebShell::SetupNewViewer(nsWebShell * const 0x035b5730, nsIContentViewer * 
0x031d6900) line 350 + 13 bytes
nsDocShell::Embed(nsDocShell * const 0x035b5750, nsIContentViewer * 0x031d6900, 
const char * 0x01cdf624, nsISupports * 0x00000000) line 2409 + 23 bytes
nsWebShell::Embed(nsWebShell * const 0x035b5750, nsIContentViewer * 0x031d6900, 
const char * 0x01cdf624, nsISupports * 0x00000000) line 383
nsDocShell::CreateContentViewer(nsDocShell * const 0x035b5730, const char * 
0x0012f8ec, nsIChannel * 0x035b4340, nsIStreamListener * * 0x0012f940) line 2588 
+ 32 bytes
nsDSURIContentListener::DoContent(nsDSURIContentListener * const 0x035b5370, 
const char * 0x0012f8ec, int 0, const char * 0x100a56c8 gCommonEmptyBuffer, 
nsIChannel * 0x035b4340, nsIStreamListener * * 0x0012f940, int * 0x0012f8d0) 
line 106 + 33 bytes
nsDocumentOpenInfo::DispatchContent(nsIChannel * 0x035b4340, nsISupports * 
0x00000000) line 359 + 109 bytes
nsDocumentOpenInfo::OnStartRequest(nsDocumentOpenInfo * const 0x035b70e0, 
nsIChannel * 0x035b4340, nsISupports * 0x00000000) line 233 + 16 bytes
nsHTTPFinalListener::OnStartRequest(nsHTTPFinalListener * const 0x035b7080, 
nsIChannel * 0x035b4340, nsISupports * 0x00000000) line 1122
InterceptStreamListener::OnStartRequest(InterceptStreamListener * const 
0x031d5470, nsIChannel * 0x035b4340, nsISupports * 0x00000000) line 1178
nsHTTPServerListener::FinishedResponseHeaders() line 1047 + 48 bytes
nsHTTPServerListener::OnDataAvailable(nsHTTPServerListener * const 0x035c67d0, 
nsIChannel * 0x03578c24, nsISupports * 0x035b4340, nsIInputStream * 0x035c6710, 
unsigned int 0, unsigned int 379) line 427 + 8 bytes
nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x035c7ad0) 
line 400 + 47 bytes
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x035c7a80) line 97 + 12 bytes
PL_HandleEvent(PLEvent * 0x035c7a80) line 575 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00ac71b0) line 508 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x0b9f01d2, unsigned int 49340, unsigned int 0, 
long 11301296) line 1044 + 9 bytes
USER32! 77e71820()
00
Do you know who would get this bug Rick... I watched this bug.. and it registers 
a listener in the DocumentViewerImpl::Print.. then before it gets back into 
printing.. it crashes..
Assignee: dcone → rpotts
*spam*

adding crash keyword...
Keywords: crash
I get a crash when printing from Win32 in 2000100808 under Windows95 OSR1.
Does not leave stack trace - windows crashes.
Crash happens after pressing print button in print dialog.
Happens multiple times from various URLs
2000100808 win32 on win95OSR1 - see my last comment: confirm crashes regardless 
of page being printed. - including mozilla.org homepage. crash after pressing 
print button in print dialog. can ctrl-tab for a few seconds then total system 
lock apart from mouse.
I got the following stack trace
when running the chofmann's browser buster and pressing print while the page is
not loaded completely
KERNEL32! bff768a0()
nsWindow::Create(nsWindow * const 0x038016c4, nsIWidget * 0x00000000, const
nsRect & {...}, nsEventStatus (nsGUIEvent *)* 0x02813a04 HandleEvent(nsGUIEvent
*), nsIDeviceContext * 0x011674d0, nsIAppShell * 0x00000000, nsIToolkit *
0x00000000, nsWidgetInitData * 0x00000000) line 1149
nsView::CreateWidget(nsView * const 0x03806110, const nsID & {...},
nsWidgetInitData * 0x00000000, void * 0x00000000, int 1) line 965
DocumentViewerImpl::MakeWindow(nsIWidget * 0x0117b5b4, const nsRect & {...})
line 1243 + 47 bytes
DocumentViewerImpl::Init(DocumentViewerImpl * const 0x0118b8d0, nsIWidget *
0x0117b5b4, nsIDeviceContext * 0x011674d0, const nsRect & {...}) line 542 + 16 bytes
nsDocShell::SetupNewViewer(nsDocShell * const 0x0117bb80, nsIContentViewer *
0x0118b8d0) line 2865 + 66 bytes
nsWebShell::SetupNewViewer(nsWebShell * const 0x0117bb80, nsIContentViewer *
0x0118b8d0) line 350 + 13 bytes
nsDocShell::Embed(nsDocShell * const 0x0117bba0, nsIContentViewer * 0x0118b8d0,
const char * 0x01db227c, nsISupports * 0x00000000) line 2497 + 23 bytes
nsWebShell::Embed(nsWebShell * const 0x0117bba0, nsIContentViewer * 0x0118b8d0,
const char * 0x01db227c, nsISupports * 0x00000000) line 383
nsDocShell::CreateContentViewer(nsDocShell * const 0x0117bb80, const char *
0x007acd2c, nsIChannel * 0x0117e4d0, nsIStreamListener * * 0x007acd80) line 2678
+ 32 bytes
nsDSURIContentListener::DoContent(nsDSURIContentListener * const 0x0117b880,
const char * 0x007acd2c, int 0, const char * 0x100a66c8 gCommonEmptyBuffer,
nsIChannel * 0x0117e4d0, nsIStreamListener * * 0x007acd80, int * 0x007acd10)
line 103 + 33 bytes
nsDocumentOpenInfo::DispatchContent(nsIChannel * 0x0117e4d0, nsISupports *
0x00000000) line 359 + 109 bytes
nsDocumentOpenInfo::OnStartRequest(nsDocumentOpenInfo * const 0x0117e050,
nsIChannel * 0x0117e4d0, nsISupports * 0x00000000) line 233 + 16 bytes
nsHTTPFinalListener::OnStartRequest(nsHTTPFinalListener * const 0x0117cfc0,
nsIChannel * 0x0117e4d0, nsISupports * 0x00000000) line 1122
nsHTTPCacheListener::OnStartRequest(nsHTTPCacheListener * const 0x0117c3b0,
nsIChannel * 0x0117c280, nsISupports * 0x00000000) line 150
nsDiskCacheRecordChannel::OnStartRequest(nsDiskCacheRecordChannel * const
0x0117c284, nsIChannel * 0x011799d0, nsISupports * 0x00000000) line 704
nsOnStartRequestEvent::HandleEvent(nsOnStartRequestEvent * const 0x01179670)
line 210 + 26 bytes
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x01179620) line 97 + 12 bytes
PL_HandleEvent(PLEvent * 0x01179620) line 576 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00b8b330) line 509 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x00000a34, unsigned int 55666, unsigned int 0,
long 12104496) line 1054 + 9 bytes
KERNEL32! bff7363b()
KERNEL32! bff94407()
Summary: Crashes while printing page → Crashes while printing page [@nsWindow::Create]
My last attached stack trace has only two more lines than a topcrash
unidentified yet in the ns6analysis.html file. (DocumentViewerImpl::MakeWindow).
Adding keyword topcrash and namachi@netscape.com to check whether it is really a
topcrash.
Keywords: topcrash
resource:///res/samples/test9.html
 is another great page to print out and to crash. I think this should be fixed
before rtm, so I nominate this bug for rtm.
Keywords: rtm
Rick,
I saw docone's question about who you thought should get this bug.. but didn't
hear back.  Any comments?  Do you think this is yours... but are you too overloaded?
Thanks,
Jim
I get a crash about 80% of the time on Win98, printing web pages and email messages.
If I create a printer on WinNT that prints to a PostScript file, the attached 
testcase (unzip it) will crash everytime in nsWindow::Create

I am not sure if this is exactly the same bug or not.
I haven't been able to reproduce the crash yet, but I can get into an annoying 
infinite loop of assertions by hitting print button and OK during loading.

BuildDIB complains that it is passed a 32 bit bitmap. It complains once for 
every view while painting the frame.

NTDLL! 77f7629c()
nsDebug::Assertion(const char * 0x013a29b0, const char * 0x013a29a4, const char 
* 0x013a2970, int 1138) line 256 + 13 bytes
BuildDIB(tagBITMAPINFOHEADER * * 0x0407924c, int 132, int 66, int 32, char * 
0x040791fc) line 1138 + 35 bytes
nsImageWin::ConvertDDBtoDIB(int 660, int 330) line 1103 + 48 bytes
nsImageWin::PrintDDB(void * 0x03a27a30, int 40, int 40, int 660, int 330, 
unsigned int 13369376) line 1066
nsImageWin::Draw(nsImageWin * const 0x040791f0, nsIRenderingContext & {...}, 
void * 0x03a27a30, int 40, int 40, int 660, int 330) line 706
nsRenderingContextWin::DrawImage(nsRenderingContextWin * const 0x03a24590, 
nsIImage * 0x040791f0, const nsRect & {...}) line 2836
nsImageFrame::Paint(nsImageFrame * const 0x012cfa44, nsIPresContext * 
0x05495110, nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer 
eFramePaintLayer_Overlay) line 648
nsContainerFrame::PaintChild(nsIPresContext * 0x05495110, nsIRenderingContext & 
{...}, const nsRect & {...}, nsIFrame * 0x012cfa44, nsFramePaintLayer 
eFramePaintLayer_Overlay) line 211
nsContainerFrame::PaintChildren(nsIPresContext * 0x05495110, nsIRenderingContext 
& {...}, const nsRect & {...}, nsFramePaintLayer eFramePaintLayer_Overlay) line 
155
nsHTMLContainerFrame::Paint(nsHTMLContainerFrame * const 0x012cfa0c, 
nsIPresContext * 0x05495110, nsIRenderingContext & {...}, const nsRect & {...}, 
nsFramePaintLayer eFramePaintLayer_Overlay) line 108
nsContainerFrame::PaintChild(nsIPresContext * 0x05495110, nsIRenderingContext & 
{...}, const nsRect & {...}, nsIFrame * 0x012cfa0c, nsFramePaintLayer 
eFramePaintLayer_Overlay) line 211
nsBlockFrame::PaintChildren(nsIPresContext * 0x05495110, nsIRenderingContext & 
{...}, const nsRect & {...}, nsFramePaintLayer eFramePaintLayer_Overlay) line 
6403
nsBlockFrame::Paint(nsBlockFrame * const 0x012cf9c0, nsIPresContext * 
0x05495110, nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer 
eFramePaintLayer_Overlay) line 6281
nsContainerFrame::PaintChild(nsIPresContext * 0x05495110, nsIRenderingContext & 
{...}, const nsRect & {...}, nsIFrame * 0x012cf9c0, nsFramePaintLayer 
eFramePaintLayer_Overlay) line 211
nsContainerFrame::PaintChildren(nsIPresContext * 0x05495110, nsIRenderingContext 
& {...}, const nsRect & {...}, nsFramePaintLayer eFramePaintLayer_Overlay) line 
155
nsTableCellFrame::Paint(nsTableCellFrame * const 0x012cf960, nsIPresContext * 
0x05495110, nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer 
eFramePaintLayer_Overlay) line 366
nsTableRowFrame::PaintChildren(nsIPresContext * 0x05495110, nsIRenderingContext 
& {...}, const nsRect & {...}, nsFramePaintLayer eFramePaintLayer_Overlay) line 
599
nsTableRowFrame::Paint(nsTableRowFrame * const 0x012cf910, nsIPresContext * 
0x05495110, nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer 
eFramePaintLayer_Overlay) line 552
nsTableRowGroupFrame::PaintChildren(nsIPresContext * 0x05495110, 
nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer 
eFramePaintLayer_Overlay) line 273
nsTableRowGroupFrame::Paint(nsTableRowGroupFrame * const 0x012cf8cc, 
nsIPresContext * 0x05495110, nsIRenderingContext & {...}, const nsRect & {...}, 
nsFramePaintLayer eFramePaintLayer_Overlay) line 227
nsContainerFrame::PaintChild(nsIPresContext * 0x05495110, nsIRenderingContext & 
{...}, const nsRect & {...}, nsIFrame * 0x012cf8cc, nsFramePaintLayer 
eFramePaintLayer_Overlay) line 211
nsContainerFrame::PaintChildren(nsIPresContext * 0x05495110, nsIRenderingContext 
& {...}, const nsRect & {...}, nsFramePaintLayer eFramePaintLayer_Overlay) line 
155
nsTableFrame::Paint(nsTableFrame * const 0x012cf864, nsIPresContext * 
0x05495110, nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer 
eFramePaintLayer_Overlay) line 1370
nsContainerFrame::PaintChild(nsIPresContext * 0x05495110, nsIRenderingContext & 
{...}, const nsRect & {...}, nsIFrame * 0x012cf864, nsFramePaintLayer 
eFramePaintLayer_Overlay) line 211
nsTableOuterFrame::Paint(nsTableOuterFrame * const 0x012cf810, nsIPresContext * 
0x05495110, nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer 
eFramePaintLayer_Overlay) line 352
nsContainerFrame::PaintChild(nsIPresContext * 0x05495110, nsIRenderingContext & 
{...}, const nsRect & {...}, nsIFrame * 0x012cf810, nsFramePaintLayer 
eFramePaintLayer_Overlay) line 211
nsBlockFrame::PaintChildren(nsIPresContext * 0x05495110, nsIRenderingContext & 
{...}, const nsRect & {...}, nsFramePaintLayer eFramePaintLayer_Overlay) line 
6403
nsBlockFrame::Paint(nsBlockFrame * const 0x012cf710, nsIPresContext * 
0x05495110, nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer 
eFramePaintLayer_Overlay) line 6281
nsContainerFrame::PaintChild(nsIPresContext * 0x05495110, nsIRenderingContext & 
{...}, const nsRect & {...}, nsIFrame * 0x012cf710, nsFramePaintLayer 
eFramePaintLayer_Overlay) line 211
nsBlockFrame::PaintChildren(nsIPresContext * 0x05495110, nsIRenderingContext & 
{...}, const nsRect & {...}, nsFramePaintLayer eFramePaintLayer_Overlay) line 
6403
nsBlockFrame::Paint(nsBlockFrame * const 0x012cf688, nsIPresContext * 
0x05495110, nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer 
eFramePaintLayer_Overlay) line 6281
nsContainerFrame::PaintChild(nsIPresContext * 0x05495110, nsIRenderingContext & 
{...}, const nsRect & {...}, nsIFrame * 0x012cf688, nsFramePaintLayer 
eFramePaintLayer_Overlay) line 211
nsContainerFrame::PaintChildren(nsIPresContext * 0x05495110, nsIRenderingContext 
& {...}, const nsRect & {...}, nsFramePaintLayer eFramePaintLayer_Overlay) line 
155
nsContainerFrame::Paint(nsContainerFrame * const 0x012cf650, nsIPresContext * 
0x05495110, nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer 
eFramePaintLayer_Overlay) line 134
PresShell::Paint(PresShell * const 0x05496914, nsIView * 0x03a26a80, 
nsIRenderingContext & {...}, const nsRect & {...}) line 4662 + 34 bytes
nsView::Paint(nsView * const 0x03a26a80, nsIRenderingContext & {...}, const 
nsRect & {...}, unsigned int 128, int & 268600437) line 284
nsViewManager2::RenderDisplayListElement(DisplayListElement2 * 0x03a256c0, 
nsIRenderingContext & {...}) line 859
nsViewManager2::RenderViews(nsIView * 0x03a26a80, nsIRenderingContext & {...}, 
const nsRect & {...}, int & 0) line 806
nsViewManager2::Display(nsViewManager2 * const 0x05496820, nsIView * 0x03a26a80) 
line 2312
nsSimplePageSequenceFrame::Print(nsSimplePageSequenceFrame * const 0x012cf64c, 
nsIPresContext * 0x05495110, const nsPrintOptions & {...}, 
nsIPrintStatusCallback * 0x00000000) line 438
DocumentViewerImpl::PrintContent(DocumentViewerImpl * const 0x053239d8, 
nsIWebShell * 0x03a00abc, nsIDeviceContext * 0x053812e0) line 1051
DocumentViewerImpl::DocumentReadyForPrinting() line 1368 + 32 bytes
DocumentViewerImpl::Print(DocumentViewerImpl * const 0x053239d8, int 0, _iobuf * 
0x00000000, nsIPrintListener * 0x00000000) line 1693
nsBrowserInstance::Print(nsBrowserInstance * const 0x03a72520) line 1478 + 29 
bytes
XPTC_InvokeByIndex(nsISupports * 0x03a72520, unsigned int 33, unsigned int 0, 
nsXPTCVariant * 0x0012dc0c) line 139
nsXPCWrappedNativeClass::CallWrappedMethod(JSContext * 0x01847690, 
nsXPCWrappedNative * 0x03a73b40, const XPCNativeMemberDescriptor * 0x03a73f24, 
nsXPCWrappedNativeClass::CallMode CALL_METHOD, unsigned int 0, long * 
0x0124ff08, long * 0x0012ddc0) line 913 + 43 bytes
WrappedNative_CallMethod(JSContext * 0x01847690, JSObject * 0x00ff1438, unsigned 
int 0, long * 0x0124ff08, long * 0x0012ddc0) line 228 + 34 bytes
js_Invoke(JSContext * 0x01847690, unsigned int 0, unsigned int 0) line 790 + 23 
bytes
js_Interpret(JSContext * 0x01847690, long * 0x0012e8d0) line 2589 + 15 bytes
js_Invoke(JSContext * 0x01847690, unsigned int 1, unsigned int 2) line 807 + 13 
bytes
js_InternalInvoke(JSContext * 0x01847690, JSObject * 0x00ff0d78, long 19558480, 
unsigned int 0, unsigned int 1, long * 0x0012ea68, long * 0x0012e9f8) line 879 + 
20 bytes
JS_CallFunctionValue(JSContext * 0x01847690, JSObject * 0x00ff0d78, long 
19558480, unsigned int 1, long * 0x0012ea68, long * 0x0012e9f8) line 3193 + 31 
bytes
nsJSContext::CallEventHandler(nsJSContext * const 0x01847840, void * 0x00ff0d78, 
void * 0x012a7050, unsigned int 1, void * 0x0012ea68, int * 0x0012ea64, int 0) 
line 907 + 33 bytes
nsJSEventListener::HandleEvent(nsIDOMEvent * 0x052ac5f4) line 154 + 64 bytes
nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x03a8add0, 
nsIDOMEvent * 0x052ac5f4, nsIDOMEventTarget * 0x03a89618, unsigned int 8, 
unsigned int 7) line 788 + 19 bytes
nsEventListenerManager::HandleEvent(nsIPresContext * 0x026f3dc0, nsEvent * 
0x0012f2cc, nsIDOMEvent * * 0x0012f264, nsIDOMEventTarget * 0x03a89618, unsigned 
int 7, nsEventStatus * 0x0012f310) line 1670 + 39 bytes
nsXULElement::HandleDOMEvent(nsXULElement * const 0x03a89610, nsIPresContext * 
0x026f3dc0, nsEvent * 0x0012f2cc, nsIDOMEvent * * 0x0012f264, unsigned int 1, 
nsEventStatus * 0x0012f310) line 3305
PresShell::HandleDOMEventWithTarget(PresShell * const 0x026f3060, nsIContent * 
0x03a89610, nsEvent * 0x0012f2cc, nsEventStatus * 0x0012f310) line 4963 + 39 
bytes
nsButtonBoxFrame::MouseClicked(nsIPresContext * 0x026f3dc0, nsGUIEvent * 
0x0012f498) line 138
nsButtonBoxFrame::HandleEvent(nsButtonBoxFrame * const 0x011ce050, 
nsIPresContext * 0x026f3dc0, nsGUIEvent * 0x0012f498, nsEventStatus * 
0x0012f7b8) line 99
PresShell::HandleEventInternal(nsEvent * 0x0012f498, nsIView * 0x00000000, 
unsigned int 1, nsEventStatus * 0x0012f7b8) line 4931 + 38 bytes
PresShell::HandleEventWithTarget(PresShell * const 0x026f3060, nsEvent * 
0x0012f498, nsIFrame * 0x011ce050, nsIContent * 0x03a89610, unsigned int 1, 
nsEventStatus * 0x0012f7b8) line 4897 + 22 bytes
nsEventStateManager::CheckForAndDispatchClick(nsEventStateManager * const 
0x03825dc0, nsIPresContext * 0x026f3dc0, nsMouseEvent * 0x0012f8c8, 
nsEventStatus * 0x0012f7b8) line 1863 + 61 bytes
nsEventStateManager::PostHandleEvent(nsEventStateManager * const 0x03825dc8, 
nsIPresContext * 0x026f3dc0, nsEvent * 0x0012f8c8, nsIFrame * 0x011ce050, 
nsEventStatus * 0x0012f7b8, nsIView * 0x026f36f0) line 940 + 28 bytes
PresShell::HandleEventInternal(nsEvent * 0x0012f8c8, nsIView * 0x026f36f0, 
unsigned int 1, nsEventStatus * 0x0012f7b8) line 4936 + 43 bytes
PresShell::HandleEvent(PresShell * const 0x026f3064, nsIView * 0x026f36f0, 
nsGUIEvent * 0x0012f8c8, nsEventStatus * 0x0012f7b8, int 1, int & 1) line 4851 + 
25 bytes
nsView::HandleEvent(nsView * const 0x026f36f0, nsGUIEvent * 0x0012f8c8, unsigned 
int 28, nsEventStatus * 0x0012f7b8, int 1, int & 1) line 379
nsViewManager2::DispatchEvent(nsViewManager2 * const 0x026f38d0, nsGUIEvent * 
0x0012f8c8, nsEventStatus * 0x0012f7b8) line 1439
HandleEvent(nsGUIEvent * 0x0012f8c8) line 68
nsWindow::DispatchEvent(nsWindow * const 0x026f35b4, nsGUIEvent * 0x0012f8c8, 
nsEventStatus & nsEventStatus_eIgnore) line 682 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f8c8) line 703
nsWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 3903 + 
21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 
4113
nsWindow::ProcessMessage(unsigned int 514, unsigned int 0, long 3146795, long * 
0x0012fc44) line 2973 + 24 bytes
nsWindow::WindowProc(HWND__ * 0x01b10a14, unsigned int 514, unsigned int 0, long 
3146795) line 958 + 27 bytes
USER32! 77e71820()
JS3250! ??_C@_08JKC@crtdll?4c?$AA@ + 7971 bytes

It seems like a few things are going on...

Don, I'm seeing an assert in nsWindow::StandardWindowCreate(...) because the 
call to ::CreateWindowEx(...) fails.

There is also some rather strange code in 
nsDocumentViewerImpl::PrintContent(...).  It looks in rev 1.75 of 
nsDocumentViewer.cpp rods added some code to fix bug #47478.  This code only 
works inside of viewer - not Mozilla :-(  The problem is that 
nsIDocShellTreeItem::GetParent(...) is called.  Unfortunately, this will return 
chrome parents...  So, for Mozilla it will *never* be null.  I believe that it 
should be calling nsIDocShellTreeItem::GetSameTypeParent(...).

However, it looks like the real cause behind the crash is that the PresShell 
created for printing is destroyed when PrintContent(...) returns.

However, it looks like the real cause behind the crash is that PrintContent() 
does not wait for "linked content" (ie. frames and images) to be loaded...
Unless I'm mistaken, PresShell::InitialReflow(...) is not synchronous (when 
frames and images are involved)!
So, what appears to happen is the following:
1. PrintContent(...) Creates a new PresShell for printing...
2. The document is set up inside of the PresShell - along with a new ViewManager 
and everything else it needs...
3. InitialReflow(...) is called on the PresShell - This will cause 
HTMLFrameInnerFrames to create new DocShells and *start* loading their content
4. The PresShell is told to print via its PageSequenceFrame...
5. The PresShell is destroyed (when leaving the scope of PrintContent()).  This 
causes the frame model to be destroyed along with the child DocShells that were 
created...  When the DocShell is destroyed, it "unhooks" itself from its 
nsDSURIContentListener...
6. At some point the data for the frame arrives at the URI loader.
7. The URILoader calls DoContent(...) on the nsDSURIContentListener, but its 
DocShell has already been destroyed - and we crash.
adding dcone and rods to cc list
Rick.. your correct in your description of why this crashes.. but you missed one 
thing... we call InitialRelow 2 times.. the first time we call it you added an 
observer that will tell us when all the URL's are loaded that make up the print 
job.. then and only then should the the PrintContent be called and the 
InitialReflow be called and Reflowed without the need to load any URL's.  This 
will insure that the PresShell is created, used and destroyed in the proper 
order.  What I think broke it the mechanism that observes the loading.  When I 
go to print a document with a large image.. the observer will never get 
started.. and that is a problem.. it always was started before..then the 
printing waited for the image to load before anything started.  Now it just 
falls thru and printing always starts when all the URL's are not loaded, 
printing will not support this incremental reflow.. I know tables will choke (or 
used to until karnaze checked for Null pointers there).  

On another issue.. Rod did change his code to what you suggested and this did 
not stop the crash.  Another way to do what Rod did would be to remove all that 
code and print all the WebShell no matter if it is a leaf or not.  This would 
print the FrameSet pages as well.. a few wasted pieces of paper until Frame Sets 
could print.
So don,
I looked at the code again and I don't understand what is going on...

As you said, in nsDocumentViewer::Print() we create the following components and 
then add ourselves as an ImageGroupObserver...
- DeviceContext (mPrintDC)
- PrintContext  (mPrintPC)
- StyleSet      (mPrintSS)
- PresShell     (mPrintPS)
- ViewManager   (mPrintVM)
- View          (mPrintView)

Then, once InitialReflow has finished (ie. the image observer is fired) 
PrintContent(...) is called.  However, the following components are created 
locally a *second* time:
- PrintContext (cx)
- StyleSet     (ss)
- PresShell    (ps)
- ViewManager  (vm)
- View         (view)

InitialRefow() is then called on the new PresShell (ps).  Unfortunately, this 
will cause any images to be fetched from the network a *second* time....

Since nsIPageSequenceFrame::Print() is called immediately after the call to 
ps->InitialReflow() it is unlikely that any images will have been loaded - so, 
they do not appear.

Why must we reflow twice? And create two sets of components?

In my local tree, I hacked PrintContent(...) to print mPrintPS and the images 
showed up fine...

What's going on?
-- rick
On another note...  Being an ImageGroup observer does not insure that the page 
has finished loading in framesets are involved.

Currently, in the frameset case the notification from the image group observer 
will come before the child frames have loaded.  The only way to know that the 
entire document has finished is to observer the nsIWebProgressListener 
notifications...
Unfortunately, since printing causes the document to be loaded via the 
PresShell, the WebProgress component knows nothing about the load, so no 
notifications are fired :-(

However, I don't think that we really *want* to re-create the DocShells 
associated with frames...

it seems to me that we want to force each DocShell (frame) to lay itself out, 
without recreating its children...  I don't know how this would be done :-)
-- rick
That is correct..the first time the:
- DeviceContext (mPrintDC)
- PrintContext  (mPrintPC)
- StyleSet      (mPrintSS)
- PresShell     (mPrintPS)
- ViewManager   (mPrintVM)
- View          (mPrintView)
get created and initialReflow is called is only for loading all the URLS 
(images) into the cache. If the image observer is fired, that is notification  
for printing to wait until we are notified that the images have been loaded.  If 
the image observer did not fire.. then the images are already in the cache and 
printing can proceed.  (the problem now is that the observer NEVER fires even 
when the images are not loaded into the cache)

If printing is notified to proceed, the printContent will construct new 
instances of the above for each invocation.. since this routine can get called 
for each Frame in a frameset.. basically we are laying out new documents for 
each frame in a frameset.  

As I recall.. you helped me with this implementation.. especially the observer 
part (I think you wrote most of it.. and even re-arranged the routines to be 
called at the correct times).  And I know Troy blessed this also.. as the only 
way we could print without any incremental reflows (which printing cannot 
handle).  This was all working great for about a year..until recently the 
observer never gets fired off.. and printing will do incremental reflows.. which 
broke tables (karnaze was not checking for null pointers.. now fixed) and I 
suspect a few other layout areas.  I know images are now broken because my test 
case (a huge image) never fires off this observer.. and the page will print out 
blank.  When all is working.. this image will print.
We can talk on the phone if I am confusing you.
hey don,
So it turns out that most of my image-printing woes were because I had disabled 
my image cache :-(

When the image cache is working correctly, I don;t have any problems printing 
pages without framesets...

Have you talked with rods about calling InitialReflow on frameset pages?

Should I give this bug back to you now?
*** Bug 53456 has been marked as a duplicate of this bug. ***
Is this really still a topcrash?  Isn't using the image cache the default?
Perhaps this could be rtm- then?
Whiteboard: [need minus]
The crash still occures with nice reproducibility on test9.html which is a page
with frames. I think the analysis related to the image cache was misleading and
the original problem including the dupe has not gone away. I think the bug
should be renamed : crash while printing pages with frames. Since the rtm- is
your decision I would like to warn you, that printing pages with frames is not
that seldom.
This crash used to be topcrash in talkback. Use the following URL to verify  
topcrashes for the past ten(10) days.

http://beckett.mcom.com/talkback/rankoutput.html
Marking the status whiteboard with "rtm need info" since the old value of "need
minus" was not searched for, and equivalent to no marking whatever.
IF there is a clearly safe null pointer check (or equivalent provable correction
not requiring a great deal of context), please pose that patch RSN with
approvals and review.  IF this is a complex bug (to avoid the crash) then we
will be sadly stuck with it for RTM.
Whiteboard: [need minus] → [rtm need info]
This bug is *not* related to the image cache.

It is caused by incorrectly calling InitialReflow(...) on frameset documents.

-- rick
rtm-, not stopping for this.
Whiteboard: [rtm need info] → [rtm-]
Hello, I am a user, not developer. I appreciate all the Mozilla voluntary effort
and glad to see your success. So please somebody fix this bug so we can use the
browser fully.  - - John

this is a ping to rpotts:
in

http://www.mozilla.org/status/2000-11-08.html

you wrote:

Bug #54004 - Printing documents with framesets causes random crashes. I tracked
down the cause of this problem and talked with dcone about it... If no progress
is made, I'll submit a patch...

Seems that no progress is made.... Win98 CVS 20001125

Another page with the priting crasher for verification purposes.  Real live URL
that people would probably print.

http://www.mcafee.com/anti-virus/viruses/prolin/default.asp




Is this bug well-assigned?  If it's not rpotts' bug, is it dcones?

/be
I can't tell whether it is the same bug, but I get a crash on printing this 
URL:

http://support.microsoft.com/support/kb/articles/q69/0/13.asp

Is it relevant that many of these problems are on .asp pages?

spam : changing qa to sujay (new qa contact for Printing)
QA Contact: shrir → sujay
Keywords: nsbeta1
Reassigning to dcone.
Don thinks he checked in a fix a few weeks that should fix this bug.
Assignee: rpotts → dcone
both pages print now.. this was fixed the loading problem I fixed a while ago.
Fixed
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
verified in 2/26 build.
Status: RESOLVED → VERIFIED
Crash Signature: [@nsWindow::Create]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: