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: