174579 - Browser crashes with JavaScript calendar [@ OnLinkClickEvent::OnLinkClickEvent ]

Status: RESOLVED WORKSFORME

(Core :: DOM: Navigation, defect)

Description

[Thomas Themel]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021015
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021015

The page at the above URL is a stripped sample from our project tracking system. 
Normally, by clicking on the icon right of the date box, you should get a popup
window displaying a monthly calendar. Upon clicking a date, the calendar closes
and the selected day is entered in the form field. 

In Mozilla, however, this leads to an access violation and subsequent crash.


Reproducible: Always

Steps to Reproduce:
1. Load <http://www.cpointc.com/~themel/TPRecord.cpsp.html>
2. Click calendar.gif button
3. Click on any day in the calendar.
4. Watch the flames.

Actual Results:  
Mozilla crash in DOCSHELL.DLL.

Expected Results:  
Set the text in the date field to the day I clicked.

Comment 1

[Thomas Themel]

Attachment: ZIP version of the crash page

Comment 2

[Thomas Themel]

Attachment: call stack after crash

Grabbed from MSVC++ 6 and 'Cancel' after crash.

Comment 3

[Roland Sippel]

Site Calender dont work! Nothing happens by click.
Error 404 - Not Found
The document you requested, /images/prevMonth.gif, could not be found.
and other errors.

Error 404 - Not Found
The document you requested,
/~themel/TPRecord.cpsp_files/powered-by-centerpoint.jpg, could not be found.

w2k. Gecko/20020724

Comment 4

[greer]

Reporter, please post a Talkback ID so that we can retreive a fully resolved stack.

Comment 5

[Thomas Themel]

Regarding the 
| w2k. Gecko/20020724
comment, I've tried with older versions, and it seems to work just fine there.
I also tried yesterday's i686-linux build, which also works as it should.

Talkback IDs of crashes I produced while testing yesterday:

TB12591259H
TB12590851X
TB12589919Q 
TB12589540Z

Comment 6

[Adam Lock]

Stack trace from callback, possibly the line that NS_ADDREFs aHandler is
triggering it.

0x00000000
OnLinkClickEvent::OnLinkClickEvent
[c:/builds/seamonkey/mozilla/docshell/base/nsWebShell.cpp, line 508]
nsWebShell::OnLinkClick
[c:/builds/seamonkey/mozilla/docshell/base/nsWebShell.cpp, line 546]
nsGenericElement::TriggerLink
[c:/builds/seamonkey/mozilla/content/base/src/nsGenericElement.cpp, line 3099]
nsGenericHTMLElement::HandleDOMEventForAnchors
[c:/builds/seamonkey/mozilla/content/html/content/src/nsGenericHTMLElement.cpp,
line 1495]
nsHTMLAreaElement::HandleDOMEvent
[c:/builds/seamonkey/mozilla/content/html/content/src/nsHTMLAreaElement.cpp,
line 233]
nsGenericDOMDataNode::HandleDOMEvent
[c:/builds/seamonkey/mozilla/content/base/src/nsGenericDOMDataNode.cpp, line 829]
PresShell::HandleEventInternal
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6220]
PresShell::HandleEventWithTarget
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6188]
nsEventStateManager::CheckForAndDispatchClick
[c:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp, line 2879]
nsEventStateManager::PostHandleEvent
[c:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp, line 1873]
PresShell::HandleEventInternal
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6241]
PresShell::HandleEvent
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6143]
nsViewManager::HandleEvent
[c:/builds/seamonkey/mozilla/view/src/nsViewManager.cpp, line 2194]
nsView::HandleEvent [c:/builds/seamonkey/mozilla/view/src/nsView.cpp, line 304]
nsViewManager::DispatchEvent
[c:/builds/seamonkey/mozilla/view/src/nsViewManager.cpp, line 1934]
HandleEvent [c:/builds/seamonkey/mozilla/view/src/nsView.cpp, line 83]
nsWindow::DispatchEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1065]
nsWindow::DispatchWindowEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1082]
nsWindow::DispatchMouseEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 5248]
ChildWindow::DispatchMouseEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 5503]
nsWindow::ProcessMessage
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 4034]
nsWindow::WindowProc
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1331]
USER32.DLL + 0x2e98 (0x77e12e98)
USER32.DLL + 0x30e0 (0x77e130e0)
USER32.DLL + 0x5824 (0x77e15824)
nsAppShellService::Run
[c:/builds/seamonkey/mozilla/xpfe/appshell/src/nsAppShellService.cpp, line 472]
main1 [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1538]
main [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1886]
WinMain [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1906]
WinMainCRTStartup()
KERNEL32.DLL + 0x17d08 (0x77e97d08) 

Comment 7

[Roland Sippel]

Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.2b) Gecko/20021018
crashes also after select.

Comment 8

[Matthias Versen [:Matti]]

*** Bug 183786 has been marked as a duplicate of this bug. ***

Comment 9

[Matthias Versen [:Matti]]

*** Bug 184387 has been marked as a duplicate of this bug. ***

Comment 10

[David Bradley]

What I found from the duped bug, was the object pointed to by aHandler is
probably dead. Usually a jump to zero indicates a dead object. Null pointers
usually crash before the jump is taken and don't have a 0x0 on the stack.

Comment 11

[Olivier Cahagne]

*** Bug 188340 has been marked as a duplicate of this bug. ***

Comment 12

[Matthias Versen [:Matti]]

*** Bug 195099 has been marked as a duplicate of this bug. ***

Comment 13

[Phil Schwartau]

The reporter from the latest duped bug noted:

"I suspect the culprit is:

<a href="javascript: self.close();"OnClick="self.close();">
Close Window</a>

Comment 14

[Adam Lock]

This might be affected by 130265 which has a fix just going through review right
now.

Comment 15

[Adam Lock]

WFM in latest build. Please test and verify the issue has been fixed

Comment 16

[Thomas Themel]

Works nicely as of the Build ID: 2003052209, so I consider it fixed.

I'm leaving the status at what it is right now since I wasn't able to find any
guidelines on what I'm supposed to do.