112052 - Mozilla 0.9.6 crashes after choosing an item in a list with auto-send (Regression)

Status: RESOLVED DUPLICATE of bug 112241

(Core :: Layout: Form Controls, defect)

Description

[Frédéric Bothamy]

On Compaq's site, when you choose a configuration for a computer, you are
presented with several lists to choose specific parts. Mozilla 0.9.6 (Build
2001112012) starts by asking to send the information of the page. I hit Cancel.
Then, after selecting one item in a list (more memory for instance), Mozilla
0.9.6 segfaults after a few seconds when the list stays open. Tested under Linux
and MacOS 9.1 (Mozilla 0.9.6 each time). It does not happen with Mozilla 0.9.5
(Build 2001101202) under Linux which I use to write this bug report, but Mozilla
keeps sending some data (which seems to be consistent with the webpage contents
and the javascript on the page).

Comment 1

[Asa Dotzler [:asa]]

If you are crashing in Mozilla the best thing you can do to help the developers
fix your bug is to attach a stacktrace. If you're not building yourself you are
not out of luck.  Mozilla (thanks to a very cool donation from Netscape)
releases nightly and milestone builds with Full Circle's Talkback. Talkback
should catch most crashes and offer to send in a crash report. I can retrieve
that crash report and attach it to your bug report if you provide either the
Incident ID (you can get it by running the talkback program from
/components/talkback/) or you can let me know the email address you used to
submit the report and the time of sending. Thanks for your help in testing
Mozilla and reporting bugs.

Comment 2

[Diego Biurrun]

I also crash with 2001121715 and 2001121606 with no talkback triggered ---> NEW

TB652096Z

Comment 3

[Diego Biurrun]

Just crashed with Windows ME 0.9.7 ---> OS=All

TB978790M

Stephend, could you retrieve talkback data, please?  Maybe you know in which
component this belongs.  Thanks.

Comment 4

[Asa Dotzler [:asa]]

Attachment: talkback for Incident ID 978790

nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line
3270]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line
3408]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line
3408]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line
3408]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line
3408]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line
3408]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line
3408]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line
3408]
nsXULElement::HandleChromeEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line
4634]
GlobalWindowImpl::HandleDOMEvent
[d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 632]
nsDocument::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\base\src\nsDocument.cpp, line 3058]
nsGenericElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\base\src\nsGenericElement.cpp, line 1853]
nsGenericElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\base\src\nsGenericElement.cpp, line 1847] 

<snip>

Comment 5

[Asa Dotzler [:asa]]

->XUL

Comment 6

[John Morrison]

It turns out that this is an infinite recursion. XUL is at the top of stack 
while it is handling the capturing phase for a 'onchange' event targetted at 
the select element. But the core recursion pivots around 
nsHTMLOptionElement::SetText.

The Compaq page does the following:
1) when the selection <option> in the <select> widget changes, it triggers
   a handler for the onchange event.
2) this handler then modifies the text of each <option>
3) that causes another 'onchange' event to be posted
4) ... "and they're off" ...

I'll attach a simple test case. It does seem reasonable that the onchange 
handler for the select is called whenever a change occurs for one of it child 
option elements. Unfortunately, existing practice (DOM 0) has been to not fire 
onchange for "internally" generated changes.

Comment 7

[John Morrison]

Attachment: simple test case; if onchange handler modifies text of option elements, hilarity ensues.

Comment 8

[John Morrison]

Attachment: more detailed stack trace

Comment 9

[Brendan Eich [:brendan]]

See http://lxr.mozilla.org/classic/source/lib/libmocha/lm_input.c#2536 and
below, in fact see all the libmocha hits for event_mask in
http://lxr.mozilla.org/classic/search?string=event_mask and note the suppression
of event handler recursion.

/be

Comment 10

[rods (gone)]

-->

Comment 11

[John Morrison]

I tried jkeiser's changes for bug 112241, which is the for the same issue as 
this bug, and compaq pages do not crash with those changes. Marking dup.

*** This bug has been marked as a duplicate of 112241 ***