Closed Bug 53296 Opened 24 years ago Closed 24 years ago

Crash when printing simple doc with iframe

Categories

(Core :: DOM: Navigation, defect, P3)

x86
Windows NT
defect

Tracking

()

VERIFIED DUPLICATE of bug 47478

People

(Reporter: rods, Assigned: dcone)

References

Details

(Keywords: crash, embed, Whiteboard: [nsbeta3-][rtm-] Difficult to reproduce.)

Attachments

(1 file)

For some reason the mDocShell is null in nsDSURIContentListener::DoContent when printing this simple attachment with an iframe in it. If I put: if (mDocShell == nsnull) { return NS_OK; } at the top of the method it doesn't crash anymore (yawn)
Attached file simple testcase
The simple testcase uses test2.html as the src for the iframe. For simplicity I change test2.html to this: <html> <body> Example 2 </body> </html>
nominating for nsbeta3 because it is a crasher
Keywords: crash, nsbeta3
Blocks: 47478
Rod, I can't reproduce the crash. Is this problem still happening for you?
Yes, I did a tip pull and build this morning and it crashes. Just now I copied the contents of the attachment into test0.html in the my dist\...\res\samples directory loaded it and then printed it and it crashed (WinNT) nsDSURIContentListener::DoContent(nsDSURIContentListener * const 0x028beab0, const char * 0x0012faac, int 0, const char * 0x002d56c8 gCommonEmptyBuffer, nsIChannel * 0x028be1b0, nsIStreamListener * * 0x0012fb00, int * 0x0012fa90) line 106 + 24 bytes nsDocumentOpenInfo::DispatchContent(nsIChannel * 0x028be1b0, nsISupports * 0x00000000) line 359 + 109 bytes nsDocumentOpenInfo::OnStartRequest(nsDocumentOpenInfo * const 0x028be030, nsIChannel * 0x028be1b0, nsISupports * 0x00000000) line 233 + 16 bytes nsResChannel::OnStartRequest(nsResChannel * const 0x028be1b4, nsIChannel * 0x028bff00, nsISupports * 0x00000000) line 691 nsFileChannel::OnStartRequest(nsFileChannel * const 0x028bff08, nsIChannel * 0x028bfaf0, nsISupports * 0x00000000) line 634 nsOnStartRequestEvent::HandleEvent(nsOnStartRequestEvent * const 0x028be340) line 210 + 26 bytes nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x028be410) line 97 + 12 bytes PL_HandleEvent(PLEvent * 0x028be410) line 575 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x0110d710) line 508 + 9 bytes _md_EventReceiverProc(HWND__ * 0x00120548, unsigned int 49420, unsigned int 0, long 17880848) line 1044 + 9 bytes USER32! 77e719d0() USER32! 77e71982() NTDLL! 77f763a3() USER32! 77e718d2() nsWindow::DefaultWindowProc(HWND__ * 0x00110550, unsigned int 274, unsigned int 61458, long 655557) line 977 USER32! 77e727fe() USER32! 77e72889() nsWindow::WindowProc(HWND__ * 0x00110550, unsigned int 274, unsigned int 61458, long 655557) line 957 + 31 bytes USER32! 77e719d0() USER32! 77e71982() NTDLL! 77f763a3() USER32! 77e718d2() nsWindow::DefaultWindowProc(HWND__ * 0x00110550, unsigned int 161, unsigned int 2, long 655557) line 977 USER32! 77e727fe() USER32! 77e72889() nsWindow::WindowProc(HWND__ * 0x00110550, unsigned int 161, unsigned int 2, long 655557) line 957 + 31 bytes
Marking nsbeta3- as nsbeta3 has passed. Nominating RTM.
Keywords: rtm
Whiteboard: [nsbeta3-]
The testcase seems not complete. I cannot crash on my window by print the attachment.
Can anyone show how to reliably reproduce this? Is the proposed fix a no-brainer? It's good to get rid of crashers that people will hit, but I can't tell if this is one of them.
Whiteboard: [nsbeta3-] → [nsbeta3-][rtm need info]
Can't dup on my W2K-J. Need more info.
Whiteboard: [nsbeta3-][rtm need info] → [nsbeta3-][rtm need info] Difficult to reproduce.
Unless we can reproduce the crash consistantly, this should fall off of the rtm radar.
Keywords: embed
CC'ing dcone
This sounds like it s too hard to reproduce at this point, so I'm marking it RTM minus
Whiteboard: [nsbeta3-][rtm need info] Difficult to reproduce. → [nsbeta3-][rtm-] Difficult to reproduce.
-> don cone
Assignee: adamlock → dcone
The printing of IFrames is covered under 47478.. so I am dupping this against that bug since things will be re-written to cover this issue. *** This bug has been marked as a duplicate of 47478 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
v
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: