Closed Bug 194362 Opened 22 years ago Closed 22 years ago

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

Categories

(SeaMonkey :: General, defect)

x86
Windows XP
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 171949

People

(Reporter: jhartley, Assigned: asa)

Details

(Keywords: crash)

Crash Data

Attachments

(1 file, 1 obsolete file)

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
can you post Talkback ID for this crash using 1.3b ? see "mozilla/bin/components/talkback.exe"
Keywords: crash, stackwanted
As Requested the Talkback ID is TB17381218G The same incident on a page with a slightly different content is: TB17348623M
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.
Attached file Stack for TB 17381218
Looks like this is bombing when XPConnect tries to create a new JSObject for a wrapper. Crashes in JS_HashString from the venkman hooks
*** This bug has been marked as a duplicate of 171949 *** *** This bug has been marked as a duplicate of 171949 ***
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Keywords: stackwanted
Resolution: --- → DUPLICATE
Summary: crashes when <select> box is disabled for second time!?! → crashes when <select> box is disabled for second time!?! [@ JS_HashString]
Product: Browser → Seamonkey
Crash Signature: [@ JS_HashString]

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.

Attachment #9462061 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: