194362 - crashes when <select> box is disabled for second time!?! [@ JS_HashString]

Status: RESOLVED DUPLICATE of bug 171949

(SeaMonkey :: General, defect)

Description

[Jeremy Hartley]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130

This error occured in a fairly complicated situation using a lot of frames and
remote scripting. When a <select> box has the disabled property set to true for
the second time the browser crashes. 

It is not possible to provide all the code necessary to reproduce this example,
since you would require circa 20 files and a couple of servers just to get the
situation up and running, however this is the code fragment that did the damage:

if (control = parent.CONTENT.document.content.elements[fieldid]) {			
	if (control.className != "label"){
		var bDisable = 	statusSettings[content].readonly;														
		control.disabled = bDisable;
	}
}

The control was contained in a form called content on a Frame called content.
The original html code which generated on a server, is passed to a data frame,
which places it in the content frame using the .innerHTML property.

The sequence in which the crash occured is as follows. When the new page is
loaded into the content frame, the <select> boxes .disabled property is set to
true. Later the disabled property is set to false. Finally it is set to true
again and at this point on the execution of:

control.disabled = bDisable;

Mozilla crashes.


Reproducible: Always

Steps to Reproduce:
I have tried to make a simple page which reproduces this problem, however in the
simple case it always works fine. I can not provide the full code since it is
too large and the system is not operational.

I have however reproduced this problem on a Windows 2000 machine using both
Mozilla 1.2.1 and Mozilla 1.3b

Actual Results:  
The browser crashes

Expected Results:  
Diable the control

Comment 1

[Olivier Cahagne]

can you post Talkback ID for this crash using 1.3b ? see
"mozilla/bin/components/talkback.exe"

Comment 2

[Jeremy Hartley]

As Requested the Talkback ID is 
TB17381218G

The same incident on a page with a slightly different content is:
TB17348623M

Comment 3

[Hermann Schwab]

look at this, don´t know if it is a testcase for this bug, but it is simple, and
crashing on Win98
http://home.hccnet.nl/m.wargers/test/mozilla/f3.htm#userfile

found at: http://www.mozillazine.org/forums/viewtopic.php?t=6192

Recent Mozilla builds seem to crash when you click three times on one of the
anchors. Link:
http://home.hccnet.nl/m.wargers/test/mozilla/f3.htm#userfile
Older ones don't seem to work.
Seems to happen only in combination with position:absolute and input type=file.

Comment 4

[David Bradley]

Attachment: Stack for TB 17381218

Comment 5

[David Bradley]

Looks like this is bombing when XPConnect tries to create a new JSObject for a
wrapper. Crashes in JS_HashString from the venkman hooks

Comment 6

[timeless]

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

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

Comment 7

[Nathan Barrett [:nbarrett]]

Attachment: WIP: Bug 194362 - Add Ui for inline selection

Comment 8

[Phabricator Automation]

Comment on attachment 9462061 [details]
WIP: Bug 194362 - Add Ui for inline selection

Revision D235703 was moved to bug 1943462. Setting attachment 9462061 [details] to obsolete.