If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

crash if a DIV is hid while focus is on a form element inside it (best guess)

RESOLVED DUPLICATE of bug 212338

Status

SeaMonkey
General
--
critical
RESOLVED DUPLICATE of bug 212338
14 years ago
4 years ago

People

(Reporter: Johnny Piacentini, Unassigned)

Tracking

({crash, stackwanted, testcase})

Trunk
x86
Windows XP
crash, stackwanted, testcase

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624

I use to hide a form upon submitting to prevent the user from interacting during
page loading.
With Mozilla 1.4 final this causes a bug.
It seems that hiding a form with a focused field gets the browser angry.

Reproducible: Always

Steps to Reproduce:
1. Save the attached snippet and open it
2. Focus on the first input field
3. Type something to trigger the onchange
4. Press TAB

<HTML>
<HEAD>
	<SCRIPT language="Javascript">

	function DIV_getStyle(tID) {
		if(document.getElementById)	return document.getElementById(tID).style;
		else if(document.all)		return document.all[tID].style;
		else if(document.layers)	return document.layers[tID];
		
		return false
	}

	function DIV_hide(pID) {
		var t		= DIV_getStyle(pID)
		t.display	= 'none'
		return true
	}
	
	</SCRIPT>
</HEAD>

<BODY>

<DIV id="myDIV">

<FORM name="SHARDFORM" method="POST" action="http://www.example.com/">

<INPUT type="text" name="BOOM" value="" onChange="DIV_hide('myDIV')">
<INPUT type="text" name="foobar" value="">

</FORM>

</DIV>
</BODY>
</HTML>
Actual Results:  
Instant crash

Expected Results:  
The form fields should become hidden

Tested with a just installed, untouched Mozilla 1.4 FINAL.
No previous versions on the system.
OS is a fresh W2K with Service Pack 4. Also broken on an XP SP1.
(Reporter)

Updated

14 years ago
Flags: blocking1.5b?
Flags: blocking1.5a?
Flags: blocking1.4.x+

Comment 1

14 years ago
Created attachment 128232 [details]
Reporter's testcase

Comment 2

14 years ago
crashing build 2003072104 on Win2k, will post TB ID or stack trace.
Look very similar to bug 212338.
Keywords: crash, stackwanted, testcase

Comment 3

14 years ago
In the meantime, reassigning to Browser-General until we can get 
a stack trace. Not likely to be a JS Engine issue. Confirming bug
based on Olivier's findings -
Assignee: rogerl → general
Component: JavaScript Engine → Browser-General
QA Contact: pschwartau → general

Updated

14 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 4

14 years ago
Created attachment 128256 [details]
Camino crash log

Seeems to be a problem on the mac platform as well. With Camino 2003071004 on
Mac OS 10.1.5 the testcase makes the browser hang. The system generates a crash
log though.
Probably a dup of that other crash bug with form controls (accessing invalid
primary frame hash entries).
Whiteboard: DUPEME

Comment 6

14 years ago
stack from attachment 127480 [details] is identical.

*** This bug has been marked as a duplicate of 212338 ***
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE

Updated

14 years ago
Flags: blocking1.5b?
Flags: blocking1.5a?
Flags: blocking1.4.x+
Product: Browser → Seamonkey

Updated

4 years ago
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.