form double submit protection applies even after JS sets src and target

VERIFIED FIXED

Status

()

VERIFIED FIXED
17 years ago
16 years ago

People

(Reporter: Trevor_campbell, Assigned: john)

Tracking

Trunk
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [FIX], URL)

Attachments

(3 attachments, 3 obsolete attachments)

(Reporter)

Description

17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2)
Gecko/20020510
BuildID:    2002051006

In order to more easily handle error messages and resubmit sie effects in our
web application we use an invisible IFrame as a target for POST actions.  The
page returned to the IFrame does a redirect of the parent frame to show the next
form in the application;
The javascript code is ( for example ).
<script LANGUAGE=JAVASCRIPT>

//Redirect the outer frame to show the template jsp with all the form stuff from
//the outer form
var targetDoc;
var form;
targetDoc = window.top.document;



 form = targetDoc.forms[0];
 form.action="/kits/atune/app/incidentselectuser";
 form.target="_top";
 form.submit();

</SCRIPT>

This no longer works in Mozilla.  The action and target are correctly set (
easily checked in the DOM Inspector ) but the submit does not occur.  This works
in IE 5 & 5.5 and I think used to work in Mozzilla 0.7 or 0.8.

Reproducible: Always
Steps to Reproduce:
Build a page with a form and an Iframe in it.
Have a submit button that targets the iFrame and requests a form containing the
above style of script from the server.
submit the form.

Actual Results:  Nothing

Expected Results:  Go to new page

Comment 1

17 years ago
This works for me on a build from 05/17 on win 2k and on 2002-05-13-08-trunk on
win98

Comment 2

17 years ago
Can you please attach the source of the page that contains the iframe?
(Reporter)

Comment 3

17 years ago
Created attachment 84335 [details]
Page containing the IFrame

Attachment requested by vladimire.
(I retested with the latest nightly build (2002052008) and had the same
failure.

Comment 4

17 years ago
Ok, I saved the page as test.html, added src="test2.html" where test2.html is a
page with the script described. When I load test.html it imedeatly submits to
the action specified in the script... 

Oh, wait a second! The testcase worked when I loaded it from the server. However
when I load it with the File:// protocol it does not work! Are you loading the
testcase with File:// protocol?
(Reporter)

Comment 5

17 years ago
No I am loading from a Tomcat JSP server.  I will try a small/simple test case &
try to reproduce with that. 
(Reporter)

Comment 6

17 years ago
Created attachment 84370 [details]
Simple test script
(Reporter)

Comment 7

17 years ago
Created attachment 84371 [details]
Simple test script part 2 (redirect)

I get the same behavior with these 2 simple example .html pages
(Reporter)

Comment 8

17 years ago
Workaround by adding a delay.  The following in the redirect script gets around
the problem.
 form = targetDoc.forms[0];
 form.action="www.kaz.com.au";
 form.target="_top";
 setTimeout('form.submit()', 100);

Comment 9

17 years ago
hehe! I know what this is! Is the double form submission prevention.
the javascript in the header of the document loaded in the iframe is executing
before the document has been loaded. That's why setting a timeout helps. In that
case the document ends loading and the from can submit a second time.

Dr. Keiser, uebernehmen Sie bitte!
Assignee: alexsavulov → jkeiser

Comment 10

17 years ago
alexandru is this invalid?
(Assignee)

Comment 11

17 years ago
Nope, not invalid.  I want to disable double form submit protection when JS
changes target / action / method / etc.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Updated

17 years ago
Status: NEW → ASSIGNED
Summary: submit of parent form from iframe not working → form double submit protection applies even after JS sets src and target
(Assignee)

Comment 12

17 years ago
Created attachment 95083 [details] [diff] [review]
Patch

This patch works, with the minor problem that it crashes on shutdown.  I
haven't been able to ascertain why.
(Assignee)

Comment 13

17 years ago
Comment on attachment 95083 [details] [diff] [review]
Patch

OK, it turns out that is a general problem with today's builds (backing out
doesn't change it), this patch is up for review.
Attachment #95083 - Attachment description: Patch v0.9 (do not apply) → Patch
(Assignee)

Updated

17 years ago
Whiteboard: [FIX]
(Assignee)

Comment 14

17 years ago
Created attachment 95156 [details]
Testcase

The testcases from before don't work at all--they are missing crucial JS
functions.

The bug is about making form resubmit when you change action= or target= on the
form.  That is what this testcase does: submit,change action/target,submit
again.
Attachment #84370 - Attachment is obsolete: true
Attachment #84371 - Attachment is obsolete: true

Comment 15

17 years ago
Comment on attachment 95083 [details] [diff] [review]
Patch

aren't you going to declare the  methods GetAction and SetAction in the class
declaration  of nsHTMLFormElement?

Comment 16

17 years ago
Comment on attachment 95083 [details] [diff] [review]
Patch

sorry i was blind!

r= alexsavulov
(Assignee)

Comment 17

17 years ago
I just realized, I really want to check for this in SetAttr().
(Assignee)

Comment 18

17 years ago
Created attachment 95672 [details] [diff] [review]
Patch v2.0

This version catches SetAttr() so that setAttribute('target') and
setAttribute('action') will do the same thing.	Also extra comments and some
cleanup.
(Assignee)

Updated

17 years ago
Attachment #95083 - Attachment is obsolete: true

Comment 19

17 years ago
Comment on attachment 95672 [details] [diff] [review]
Patch v2.0

r= alexsavulov
Attachment #95672 - Flags: review+
Comment on attachment 95672 [details] [diff] [review]
Patch v2.0

sr=jst
Attachment #95672 - Flags: superreview+
(Assignee)

Comment 21

17 years ago
Fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 22

16 years ago
*** Bug 159770 has been marked as a duplicate of this bug. ***

Comment 23

16 years ago
verifying on build 2003-01-17-04-trunk win2k
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.