Closed Bug 22832 Opened 25 years ago Closed 24 years ago

return false in onclick event does not force ignorance of the action tag in form

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: tgd, Assigned: joki)

References

(
URL
)

Details

I have been spending the last few days checking the projects I am currently
involved in against the Mozilla M12 release. Unfortunately my latest project
which depends heavily on IE4 and NN4 DHTML breaks completely. So I need to
direct the Mozilla users to the version for NN3. Here is the piece of code
that I have been using:

<form name="browserform" method="get" action="v2/index.html">
 <select name="browserdropdown" size="1">
  <option value="v4">IE4, IE5, NN4 (JavaScript+CSS)</option>
  <option value="v3">IE3, NN3 (JavaScript)</option>
  <option value="v2" selected>NN2</option>
 </select>
&nbsp;&nbsp;<input type="submit" value=" &gt; "
onclick="redirect(this.form.elements[0]); return false;">
</form>

NN2, NN3, NN4, IE4 and IE5 work, but Mozilla M12 loads v3/index.html
as instructed by the onclick tag and then loads v2/index.html?
browserdropdown=v3
as instructed by the action tag. It seems that the return false
in the onclick tag is not affecting the form's default action.
Should it be so, or am I missing something?

Here is what appears on the OS shell:

nsLayoutHistoryState::AddState OOPS!. There was already a state in the hash tabl
e for the key

 url=http://loukaris.fhw.gr/paroikies/gr/v2/index.html?browserdropdown=v3

 data=browserdropdown=v3
nsLayoutHistoryState::AddState OOPS!. There was already a state in the hash
table for the key
Error loading URL http://loukaris.fhw.gr/paroikies/gr/v3/index.html
Document: Done (0.13 secs)
Error loading URL http://loukaris.fhw.gr/paroikies/gr/v2/index.html?
browserdropdown=v3
Document: Done (0.14 secs)
Error: Can't load: http://loukaris.fhw.gr/paroikies/gr/v2/index.html?
browserdropdown=v3 (804b0002)
Document http://loukaris.fhw.gr/paroikies/gr/v2/index.html?browserdropdown=v3
loaded successfully
Document: Done (0.601 secs)

The URL (not always online) is http://loukaris.fhw.gr/paroikies/gr/
Assignee: mccabe → joki
Component: Javascript Engine → Event Handling
QA Contact: rginda → janc
Reassiging to Event Handling.

See http://www.mozilla.org/js/js15.html#PLEASE for a description of what the
JavaScript Engine component covers.
This bug looks like it is a dup of bug 19201.
There is still a problem with the event handling with 3/1/2000 build on WINNT.

I modified the test case to the following.
On 4.x it shows an alert box then loads test1.html

In mozilla it shows the alert box. It doesn't load test1.html

<html>
<body>
<form name="browserform" method="get" action="test1.html">
 <select name="browserdropdown" size="1">
  <option value="v4">IE4, IE5, NN4 (JavaScript+CSS)</option>
  <option value="v3">IE3, NN3 (JavaScript)</option>
  <option value="v2" selected>NN2</option>
 </select>
&nbsp;&nbsp;<input type="submit" value=" &gt; "
onclick="alert('hello'); return true;">
</form>

</body>
</html>

Assigning M16 milestone.
Target Milestone: M16
Should be all set now.  There were two bugs really.  One which the base test 
case pointed out that returning false to the onclick event didn't stop the 
submit.  That is fixed.

The second problem was pointed out by Kevin's test case below that putting up an 
alert dialog blocked the submit from ever occurring.  This is also fixed.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Mass update:  changing qacontact to ckritzer@netscape.com
QA Contact: janc → ckritzer
Updating QA Contact.
QA Contact: ckritzer → lorca
Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
QA contact updated
QA Contact: gerardok → madhur
verified on build 2001-08-06-03-trunk
Status: RESOLVED → VERIFIED
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.