Closed Bug 10441 Opened 26 years ago Closed 26 years ago

javascript OnClick attribute crashes necko

Categories

(Core :: Networking, defect, P3)

Product:
Core
Component:
Networking
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED WORKSFORME

People

(Reporter: morse, Assigned: morse)

References

Details

Display the content shown below. A message on top appears saying "click here". Do it and you get the crash shown further below. content: <HTML> <HEAD> <SCRIPT> function loadCookies(){ top.frames[0].document.open(); top.frames[0].document.write( "<BODY>" + "<A ONCLICK=top.loadPermissions(); HREF= > Click here </A>" + "</BODY>" ); top.frames[0].document.close(); } function loadPermissions(){ top.frames[0].document.open(); top.frames[0].document.close(); } </SCRIPT> </HEAD> <FRAMESET ROWS = 25,* onLoad=loadCookies()> <FRAME SRC=about:blank> <FRAME SRC=about:blank> </FRAMESET> <NOFRAMES> <BODY> <P> </BODY> </NOFRAMES> </HTML> stacktrace at crash: NTDLL! 77f76274() nsDebug::Error(const char * 0x0a170d1c, const char * 0x0a170ce4, int 513) line 195 + 13 bytes nsHTTPChannel::Open() line 513 + 21 bytes nsHTTPChannel::AsyncRead(nsHTTPChannel * const 0x0ac33860, unsigned int 0, int -1, nsISupports * 0x00000000, nsIStreamListener * 0x0ac24610) line 184 + 8 bytes nsDocumentBindInfo::Bind(nsIURI * 0x0ac245a0, nsIStreamListener * 0x00000000) line 1662 + 33 bytes nsDocumentBindInfo::Bind(const nsString & {...}, nsIPostData * 0x00000000, nsIStreamListener * 0x00000000) line 1598 + 16 bytes nsDocLoaderImpl::LoadDocument(nsDocLoaderImpl * const 0x0a1e6de0, const nsString & {...}, const char * 0x010c7cf4, nsIContentViewerContainer * 0x0a1e6760, nsIPostData * 0x00000000, nsISupports * 0x00000000, nsIStreamObserver * 0x0a1e6940, unsigned int 0, const unsigned int 0) line 671 + 21 bytes nsWebShell::DoLoadURL(const nsString & {...}, const char * 0x010c7cf4, nsIPostData * 0x00000000, unsigned int 0, const unsigned int 0) line 1940 nsWebShell::LoadURL(nsWebShell * const 0x0a1e6760, const unsigned short * 0x00a33030, const char * 0x010c7cf4, nsIPostData * 0x00000000, int 1, unsigned int 0, const unsigned int 0) line 2103 + 31 bytes nsWebShell::LoadURL(nsWebShell * const 0x0a1e6760, const unsigned short * 0x00a33030, nsIPostData * 0x00000000, int 1, unsigned int 0, const unsigned int 0) line 1790 nsWebShell::HandleLinkClickEvent(nsIContent * 0x09dcb6cc, nsLinkVerb eLinkVerb_Replace, const unsigned short * 0x00a33030, const unsigned short * 0x00a33030, nsIPostData * 0x00000000) line 2697 OnLinkClickEvent::HandleEvent() line 2525 HandlePLEvent(OnLinkClickEvent * 0x0ac26f30) line 2538 PL_HandleEvent(PLEvent * 0x0ac26f30) line 509 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00a60360) line 470 + 9 bytes _md_EventReceiverProc(HWND__ * 0x0c7d0232, unsigned int 49404, unsigned int 0, long 10879840) line 932 + 9 bytes USER32! 77e71268() 00a60360()
See also bug 10449 which is related to this bug. But I don't believe that these two bugs are duplicates.
Assignee: gagan → warren
Posting may not be operational as yet. Warren/Chris?
Target Milestone: M9
Blocks: 10730
Assignee: warren → gagan
*** Bug 11031 has been marked as a duplicate of this bug. ***
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
think this is fixed now. reopen if someone still sees problems
Status: RESOLVED → VERIFIED
this was a little tricky to verify, because you have to resize the frame, then reload to see the click here, but it seems to work otherwise, marking verified
Blocks: 7530
Status: VERIFIED → REOPENED
I still see the problem. Re-opening. It should be mentioned that the so-called "crash" is not really a crash but merely a debug assertion failing. In a release build nothing will happen. In a debug build, control will be passed to the debugger. If you resume from the failed assertion, program executes normally. However a failed assertion is still an error and either the assertion is wrong (in which case it should be removed) or the code is wrong (in which case it should be corrected).
Resolution: FIXED → ---
Target Milestone: M9 → M10
See bug 12432 and bug 12433 which are related to this bug.
Status: REOPENED → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → FIXED
steve, I can't verify this, because it's in a debug build, can you check it out? thanks
Status: RESOLVED → REOPENED
Nope, it's not fixed. Still happens on a build that I pulled at noon today. Reopening.
In fact, not only is the debug assertion failing, but now you get a hard crash if you attempt to resume from that assertion (this wasn't happening when I initially reported the bug). The stack trace for that hard crash is shown below. This may or may not be related to the debug assertion which is the original intent of this report. nsGenericElement::GetParent(nsIContent * & 0x00000000) line 723 + 24 bytes nsHTMLAnchorElement::GetParent(const nsHTMLAnchorElement * const 0x02a8b4fc, nsIContent * & 0x00000000) line 101 + 18 bytes nsCSSFrameConstructor::FindPrimaryFrameFor(nsCSSFrameConstructor * const 0x02a3b8d0, nsIPresContext * 0x028e9f00, nsIFrameManager * 0x02a3b3f0, nsIContent * 0x02a8b4fc, nsIFrame * * 0x02a3b81c) line 7662 StyleSetImpl::FindPrimaryFrameFor(StyleSetImpl * const 0x02a3b970, nsIPresContext * 0x028e9f00, nsIFrameManager * 0x02a3b3f0, nsIContent * 0x02a8b4fc, nsIFrame * * 0x02a3b81c) line 977 FrameManager::GetPrimaryFrameFor(FrameManager * const 0x02a3b3f0, nsIContent * 0x02a8b4fc, nsIFrame * * 0x02a3b81c) line 259 PresShell::GetPrimaryFrameFor(const PresShell * const 0x02a3b7c0, nsIContent * 0x02a8b4fc, nsIFrame * * 0x02a3b81c) line 1877 + 32 bytes PresShell::HandleEvent(PresShell * const 0x02a3b7c4, nsIView * 0x02a42800, nsGUIEvent * 0x0012fac0, nsEventStatus & nsEventStatus_eIgnore) line 2056 nsView::HandleEvent(nsView * const 0x02a42800, nsGUIEvent * 0x0012fac0, unsigned int 8, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 828 nsView::HandleEvent(nsView * const 0x02a39960, nsGUIEvent * 0x0012fac0, unsigned int 8, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 813 nsView::HandleEvent(nsView * const 0x02a39a40, nsGUIEvent * 0x0012fac0, unsigned int 8, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 813 nsView::HandleEvent(nsView * const 0x02a3bbe0, nsGUIEvent * 0x0012fac0, unsigned int 28, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 813 nsViewManager::DispatchEvent(nsViewManager * const 0x02a3ca90, nsGUIEvent * 0x0012fac0, nsEventStatus & nsEventStatus_eIgnore) line 1665 HandleEvent(nsGUIEvent * 0x0012fac0) line 63 nsWindow::DispatchEvent(nsWindow * const 0x02a397d4, nsGUIEvent * 0x0012fac0, nsEventStatus & nsEventStatus_eIgnore) line 338 + 10 bytes nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012fac0) line 359 nsWindow::DispatchKeyEvent(unsigned int 132, unsigned short 116, unsigned int 116) line 1887 + 15 bytes nsWindow::OnKeyUp(unsigned int 116, unsigned int 63) line 2160 nsWindow::ProcessMessage(unsigned int 257, unsigned int 116, long -1069613055, long * 0x0012fde8) line 2393 + 40 bytes nsWindow::WindowProc(HWND__ * 0x03730776, unsigned int 257, unsigned int 116, long -1069613055) line 447 + 27 bytes USER
Assignee: gagan → morse
Status: REOPENED → NEW
Steve this doesnt look like a necko stack trace. Back to you for reassigning.
Assignee: morse → gagan
Resolution: FIXED → ---
Gagan, Isn't nsHTTPChannel in Necko? That's where the stack trace is hitting the assertion failure. Recall that this bug report is about the assertion failure, not the hard crash. The hard crash just started happening and has been put into this bug report as additional information only. If you like, I'll open a separate bug report on the hard crash. Reassigning back to you unless you tell me that nsHTTPChannel is not in necko.
There already is a bug report opened on the hard crash. It's 14703. So the only thing this bug report is complaining about is the assertion failure.
Target Milestone: M10 → M13
Status: NEW → ASSIGNED
Bulk move of all Necko (to be deleted component) bugs to new Networking component.
Is this still happening?
Probably. To find out for sure, try loading up the sample html that is included in this bug report?
Assignee: gagan → morse
Status: ASSIGNED → NEW
I don't think we have this assertion anymore. Steve, can you verify?
Status: NEW → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → WORKSFORME
From a build dated January 1, I am not seeing the crash. So I guess you can close this out. The only reason I didn't try this out in response to your earlier message is because of how old my build is. That was why I suggested that you try it out. But since it works on my build in spite of its age, I guess the bug has been fixed.
QA Contact: paulmac → tever
tever, can you confirm all is well here and mark this verified please? Thanks!
Can only see this in debug build so marking verified per Steve's comments.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.