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)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 171949
People
(Reporter: jhartley, Assigned: asa)
Details
(Keywords: crash)
Crash Data
Attachments
(1 file, 1 obsolete file)
4.79 KB,
text/plain
|
Details |
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•22 years ago
|
||
can you post Talkback ID for this crash using 1.3b ? see
"mozilla/bin/components/talkback.exe"
Keywords: crash,
stackwanted
Reporter | ||
Comment 2•22 years ago
|
||
As Requested the Talkback ID is
TB17381218G
The same incident on a page with a slightly different content is:
TB17348623M
Comment 3•22 years ago
|
||
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•22 years ago
|
||
Comment 5•22 years ago
|
||
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]
Updated•21 years ago
|
Product: Browser → Seamonkey
Updated•14 years ago
|
Crash Signature: [@ JS_HashString]
Comment 7•6 months ago
|
||
Comment 8•6 months ago
|
||
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.
Description
•