Closed Bug 10441 Opened 20 years ago Closed 20 years ago

javascript OnClick attribute crashes necko

Categories

(Core :: Networking, defect, P3)

x86
Windows NT
defect

Tracking

()

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: 20 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: 20 years ago20 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: 20 years ago20 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.