Form submit per javascript

[Victor]

Hi everybody!

I am experiencing a strange - at least for me - phenomen.
I have a func containing the following code :

alert (document.forms['photoUpload'].elements['photo_1'].value);

// document.forms['photoUpload'].submit();
document.photoUpload.submit();

This code works perfectly in the FF, but not in the IE. The alert
outputs the proper value of the element photo_1 and then the line with
submit() produces [objectError] - checked by means of try-catch and
displayed with alert(e) in the catch-block. This concerns the both
lines with the submit().

What could be a cause for this problem?

Victor

[Matt Kruse]

Victor wrote:

// document.forms['photoUpload'].submit();
document.photoUpload.submit();

The first form is preferred. Why is it commented out?

This code works perfectly in the FF, but not in the IE. The alert
outputs the proper value of the element photo_1 and then the line with
submit() produces [objectError]

First thing I would check is to make sure you don't have an input named
"submit".

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[Victor]

Matt Kruse schrieb:

Victor wrote:

// document.forms['photoUpload'].submit();
document.photoUpload.submit();

The first form is preferred. Why is it commented out?

Neither of the both wants to work here. The outcommented line has been
simply copied from the running code, never mind about it.

This code works perfectly in the FF, but not in the IE. The alert
outputs the proper value of the element photo_1 and then the line with
submit() produces [objectError]

First thing I would check is to make sure you don't have an input named
"submit".

No, I don't !

However, I have discovered that the problem gets eliminated when I try
to upload a different form rather than the 'photoUpload', which has
(!!!!) encode='multipart/form-data'. Can this be the real source of the
problem? If yes, then how to fix it? And why does it work in the FF?

Regards
Victor

[Malkavian]

"Victor" <bi******@chefmail.dewrote in message
news:11**********************@f1g2000cwa.googlegro ups.com...

Hi everybody!

I am experiencing a strange - at least for me - phenomen.
I have a func containing the following code :

alert (document.forms['photoUpload'].elements['photo_1'].value);

// document.forms['photoUpload'].submit();
document.photoUpload.submit();

This code works perfectly in the FF, but not in the IE. The alert
outputs the proper value of the element photo_1 and then the line with
submit() produces [objectError] - checked by means of try-catch and
displayed with alert(e) in the catch-block. This concerns the both
lines with the submit().

What could be a cause for this problem?

Victor

Why do you have "document.forms['photoUpload'].elements['photo_1'].value" in
the alert but "document.photoUpload"
when you call the submit function? perhaps if you had "document.photoUpload"
in the alert too or
document.forms['photoUpload'].elements['photo_1'].submit, you may get a
different result.

HTH

>

[Matt Kruse]

Victor wrote:

However, I have discovered that the problem gets eliminated when I try
to upload a different form rather than the 'photoUpload', which has
(!!!!) encode='multipart/form-data'. Can this be the real source of
the problem?

I don't know.

I would take these steps:
1. Try submitting the form manually, without javascript
2. Try taking elements out of the form until it works, then figure out which
piece made it break
3. Have a non-script fall-back, so even in the event of errors like this,
the form would still get submitted

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[Victor]

Why do you have "document.forms['photoUpload'].elements['photo_1'].value" in

the alert but "document.photoUpload" when you call the submit function? if you
had perhaps "document.photoUpload" in the alert too or
document.forms['photoUpload'].elements['photo_1'].submit, you may get a
different result.

I did try it with the 'document.forms['photoUpload']... ' in the alert
and with the 'document.photoUpload.submit()' without any different
result...

Victor

[Bart Van der Donck]

Victor wrote:

I am experiencing a strange - at least for me - phenomen.
I have a func containing the following code :

alert (document.forms['photoUpload'].elements['photo_1'].value);

// document.forms['photoUpload'].submit();
document.photoUpload.submit();

This code works perfectly in the FF, but not in the IE. The alert
outputs the proper value of the element photo_1 and then the line with
submit() produces [objectError] - checked by means of try-catch and
displayed with alert(e) in the catch-block. This concerns the both
lines with the submit().

What could be a cause for this problem?

I might have reconstructed your problem:

<script type="text/javascript">
function sV() {
alert (document.forms['photoUpload'].elements['photo_1'].value)
document.photoUpload.submit()
}
</script>
<form method="post" action="script.php" id="photoUpload">
<input type="file" name="photo_1">
<input type="button" value="click me" onClick="sV();">
</form>

IE says "document.photoUpload is empty or no object".
FF says "document.photoUpload has no properties".

There are a number of things that are not good in this kind of code.

Better:

<form method="post" action="script.php" name="photoUpload"
enctype="multipart/form-data" onSubmit="
alert(document.forms['photoUpload'].elements['photo_1'].value)">
<input type="file" name="photo_1">
<input type="submit" value="click me">
</form>

Is the alert only meant for debugging purposes ? Then the
onSubmit-handler can be left out.

--
Bart

[Bart Van der Donck]

Victor wrote:

[...]
However, I have discovered that the problem gets eliminated when I try
to upload a different form rather than the 'photoUpload', which has
(!!!!) encode='multipart/form-data'. Can this be the real source of the
problem? If yes, then how to fix it? And why does it work in the FF?

The right syntax is

enctype="multipart/form-data"

and not

encode='multipart/form-data'

AFAIK, this should normally not affect the javascript. But it's
necessary to add it for other reasons (to be technical, so that your
parsing program - e.g. PHP, ASP... - knows that the POST-request
consists of multiple parts divided by a defined separator).

--
Bart

[Bart Van der Donck]

Malkavian wrote:

"Victor" <bi******@chefmail.dewrote in message

>alert (document.forms['photoUpload'].elements['photo_1'].value);
// document.forms['photoUpload'].submit();
document.photoUpload.submit();

Why do you have "document.forms['photoUpload'].elements['photo_1'].value" in
the alert but "document.photoUpload" when you call the submit function?
perhaps if you had "document.photoUpload" in the alert too or
document.forms.['photoUpload'].elements['photo_1'].submit, you may get a
different result.

You can't do

document.forms['photoUpload'].elements['photo_1'].submit()

Perhaps you meant

document.forms['photoUpload'].submit()

The latter is a difference compared to document.photoUpload.submit()
if one uses id="photoUpload" inside the <form>-tag. In my experience
I prefer name="photoUpload" . Maybe that's just a habit.

--
Bart

[Malkavian]

"Victor" <bi******@chefmail.dewrote in message
news:11*********************@79g2000cws.googlegrou ps.com...

>Why do you have "document.forms['photoUpload'].elements['photo_1'].value"
in
the alert but "document.photoUpload" when you call the submit function?
if you
had perhaps "document.photoUpload" in the alert too or
document.forms['photoUpload'].elements['photo_1'].submit, you may get a
different result.

I did try it with the 'document.forms['photoUpload']... ' in the alert
and with the 'document.photoUpload.submit()' without any different
result...

Victor

I wasn't being picky. It's just that mixing name conventions causes a lot
of headaches.

[Malkavian]

"Bart Van der Donck" <ba**@nijlen.comwrote in message
news:11**********************@48g2000cwx.googlegro ups.com...

Malkavian wrote:

>"Victor" <bi******@chefmail.dewrote in message

>>alert (document.forms['photoUpload'].elements['photo_1'].value);
// document.forms['photoUpload'].submit();
document.photoUpload.submit();

Why do you have "document.forms['photoUpload'].elements['photo_1'].value"
in
the alert but "document.photoUpload" when you call the submit function?
perhaps if you had "document.photoUpload" in the alert too or
document.forms.['photoUpload'].elements['photo_1'].submit, you may get a
different result.

You can't do

document.forms['photoUpload'].elements['photo_1'].submit()

Perhaps you meant

document.forms['photoUpload'].submit()

Yes, I did. My bad. Thanks for pointing that out.

>
The latter is a difference compared to document.photoUpload.submit()
if one uses id="photoUpload" inside the <form>-tag. In my experience
I prefer name="photoUpload" . Maybe that's just a habit.

I do too but min is from old habit. I don't think that older
mozilla/netscape browsers recognise the ID tag but i could be wrong..

>
--
Bart

[Victor]

Somehow until now nobody has commented the fact that my code works
perfectly in the FireFox. The problem occurs only in the MSIE 6 (I did
not test it with other IE versions).

Any ideas to this point ?

Victor

[Evertjan.]

Victor wrote on 26 dec 2006 in comp.lang.javascript:

Somehow until now nobody has commented the fact that my code works
perfectly in the FireFox. The problem occurs only in the MSIE 6 (I did
not test it with other IE versions).

Any ideas to this point ?

Sure, if you do not quote, how should we know what you are talking about?

On usenet you cannot expect the last posting still or already to be on each
news server.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[Matt Kruse]

Victor wrote:

Somehow until now nobody has commented the fact that my code works
perfectly in the FireFox. The problem occurs only in the MSIE 6 (I did
not test it with other IE versions).

You still haven't posted your actual code, including HTML. How are we
supposed to help you?

Either:
a) Post a url that demonstrates the problem
or
b) Take your generated HTML, remove everything that is not necessary to show
the problem, and post the result here

I'm fairly certain your problem will be resolved very quickly.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[VK]

Victor wrote:

Somehow until now nobody has commented the fact that my code works
perfectly in the FireFox.

That's possibly because no one has seen your code so far. There were
two lines posted and corrected by respondents.

if you have a form with NAME "photoUpload" (ID is not relevant) and it
has element with NAME "photo_1" (ID is not relevant) then
document.forms['photoUpload'].elements['photo_1'].value
will give you photo_1 value (or allowed part of value if type="file")
document.forms['photoUpload'].submit()
will submit this form (unless you managed to create a control in your
form named "submit")

That works for all ever existed browsers since Netscape 2.0 If anything
fails to work then you have much more serious problems then two lines
of code. Without seeing the whole page by URL any further guessing is
rather futile.

[Victor]

Matt Kruse schrieb:

You still haven't posted your actual code, including HTML. How are we
supposed to help you?

Sorry guys, mea culpa...
Though I am afraid that the problem might me much more intrinsic than I
have believed earlier.

This is my essential code :

************************************************
CSS file contains these definitions :

div.fileinputIE { position: absolute;
left: 0px; }
div.photoUpload input.fileUpload { display:none; }
div.photoUpload input.textUpload { width:260px; }
a.formular { color:#0000cc; }

*************************************************
Than the HTML code is like this :

<script language="javascript">
function go() { document.forms['photoUpload'].submit(); }
function chooseFileMSIE () {
document.forms['photoUpload'].elements['photo_1'].click();
document.forms['photoUpload'].elements['text_1'].value =
document.forms['photoUpload'].elements['photo_1'].value;
}
</script>

<div class="photoUpload">
<div class="fileinputIE">
<form method="post" enctype="multipart/form-data"
action="multipart.php" name="photoUpload">
<input type="file" class="fileUpload" name="photo_1" />
<input type="text" class="textUpload" name="text_1" />
<a href="javascript:chooseFileMSIE();" class="formular">Open</a>
</form>
<a href="javascript:go()">Send</a>
</div>
</div>

*********************************************

I have to admit that this is not the same code like that for the FF. I
did not suppose initially that the reason might hide in the handlings
of the input type=file... But now I am rather convinced that just here
is the root of my problem.

Victor

[Evertjan.]

Victor wrote on 26 dec 2006 in comp.lang.javascript:

[..] input.fileUpload { display:none; }
[..] input.textUpload { width:260px; }

>
<script language="javascript">

use <script type='text/javascript'>

function go() { document.forms['photoUpload'].submit(); }
function chooseFileMSIE () {
document.forms['photoUpload'].elements['photo_1'].click();

why? what would that accomplish?

document.forms['photoUpload'].elements['text_1'].value =
document.forms['photoUpload'].elements['photo_1'].value;
}
</script>

[..]

<form method="post" enctype="multipart/form-data"
action="multipart.php" name="photoUpload">
<input type="file" class="fileUpload" name="photo_1" />
<input type="text" class="textUpload" name="text_1" />

use not />

<a href="javascript:chooseFileMSIE();" class="formular">Open</a>
</form>
<a href="javascript:go()">Send</a>

[..]

I don't think you are allowed to do that, under normal security
situations, but let's see:

1 there seems to be a link string to a local file in the not displayed
'photo_1' field [ how it comes there is anyones guess, but it should have
been browsed or manually inserted, which is impossible, because of the
display:none; ]

2 then by pressing "Open" you click the same by code, why?????

3 then you transfer the link string to the "text_1" field, why?

4 then, by pressing "send" probably, you want to upload this nonexistent
link to the server without the user exactly knowing what is being send?

This way you could have code transfer a password file to the server
unnoticed by the user! Browser security won't have you do that!!!!!
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[VK]

Victor wrote:

div.photoUpload input.fileUpload { display:none; }

That's what you should start with. So are we making "custom" file
control with the real one hidden, eh?

Form control with display:none is ignored by IE, that is the problem.
If you are really targeted to give your visitors a visual impression
that someone is hacking their computer - in such case use the image or
iframe hack - so leave file control visible but cover it with an image
or iframe with something joyful (or blank).

Note
"visual impression that someone is hacking their computer" because no
one of major portals is hacking type="file" so an average user mostly
knows how does her upload button look like across her favorites. A
strangely looking upload button and *especially* automated File Dialog
popup correlates well with the spooky stories about Viruses and Hackers
which that average user read so many times about. The observed behavior
is a suspicion and - in many cases - a panic with the desire
immediately leave the site. This way from the usability point of view
the regular type="file" is the best. Maybe it will not have all these
carefully chosen nifty colors and thistles that your other form
controls have. From the other side you're getting something much more
important than that: a non-compromised trust from your visitor.

So remove display:none and use img or iframe cover instead. That still
works only for the browsers "trustful" enough to let you make virtual
clicks on file controls and read file control value - all with the
default security settings. Lucky Firefox is not one of them.

Enclosed a little test to check if the current UA allows to make
virtual clicks on file controls and to read their values run-time:

<html>
<head>
<title>Test</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
</head>
<body>
<form method="POST" action="" enctype="multipart/form-data">
<fieldset>
<legend>Demo</legend>
<label for="file01" accesskey="f"><u>F</u>ile:</label>
<input type="file" name="file01" id="file01">
<br>
<input type="button" value="Virtual click on File"
onclick="this.form.file01.click()">
<input type="button" value="Show File value"
onclick="window.alert(this.form.file01.value)">
</fieldset>
</form>
</body>
</html>

[Victor]

VK schrieb:

Victor wrote:

div.photoUpload input.fileUpload { display:none; }

That's what you should start with. So are we making "custom" file
control with the real one hidden, eh?

That's correct, because my customer wants to have a single design
through the whole project. The more so, the page must be facilitated to
switch among several languages, independently on the current OS on the
user machine.

Form control with display:none is ignored by IE, that is the problem.

It is obviously not, as my alert witnesses. But its content gets
apparently only displayed, not sent - and that's the problem...

If you are really targeted to give your visitors a visual impression
that someone is hacking their computer - in such case use the image or
iframe hack - so leave file control visible but cover it with an image
or iframe with something joyful (or blank).

I tryed even to let the file input visible - it does not change the
behaviour of the form. My Send link displays the alert with the correct
file name, which has been selected by user with the Open button, and
that's all...

Note
"visual impression that someone is hacking their computer" because no
one of major portals is hacking type="file" so an average user mostly
knows how does her upload button look like across her favorites. A
strangely looking upload button and *especially* automated File Dialog
popup correlates well with the spooky stories about Viruses and Hackers
which that average user read so many times about. The observed behavior
is a suspicion and - in many cases - a panic with the desire
immediately leave the site. This way from the usability point of view
the regular type="file" is the best. Maybe it will not have all these
carefully chosen nifty colors and thistles that your other form
controls have. From the other side you're getting something much more
important than that: a non-compromised trust from your visitor.

So remove display:none and use img or iframe cover instead. That still
works only for the browsers "trustful" enough to let you make virtual
clicks on file controls and read file control value - all with the
default security settings. Lucky Firefox is not one of them.

All these considerations sound reasonably, but what about a different
point of view :
You cannot specify any style for the input 'File' - at least all of
them get ignored by any major browser. So you have to accept that on
your beautifully and carefully designed page appears an ugly button
with system color reading stubbornly in the language of the current OS
"Durchsuchen..." where all the rest is in a quite different language...
There are many cases in the world when the user does not even
understand the language of the OS, because he is an emigrant and tryes
to stay in contact with his origins through the URL I am intended to
provide for him...
I find this security policy not especially well-grounded. Allowing
styles for input file could be a sound compromise here.

Enclosed a little test to check if the current UA allows to make
virtual clicks on file controls and to read their values run-time:

<html>
<head>
<title>Test</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
</head>
<body>
<form method="POST" action="" enctype="multipart/form-data">
<fieldset>
<legend>Demo</legend>
<label for="file01" accesskey="f"><u>F</u>ile:</label>
<input type="file" name="file01" id="file01">
<br>
<input type="button" value="Virtual click on File"
onclick="this.form.file01.click()">
<input type="button" value="Show File value"
onclick="window.alert(this.form.file01.value)">
</fieldset>
</form>
</body>
</html>

Thank you VK for this small test listing. Regrettably, it could not
bring me any further in solving my problem...

Victor

[VK]

Form control with display:none is ignored by IE, that is the problem.

It is obviously not, as my alert witnesses.

Correction: display:none elements are not submitted, "ignored" was
indeed an ambiguous term.

Note
"visual impression that someone is hacking their computer" because no
one of major portals is hacking type="file" so an average user mostly
knows how does her upload button look like across her favorites. A
strangely looking upload button and *especially* automated File Dialog
popup correlates well with the spooky stories about Viruses and Hackers
which that average user read so many times about. The observed behavior
is a suspicion and - in many cases - a panic with the desire
immediately leave the site. This way from the usability point of view
the regular type="file" is the best. Maybe it will not have all these
carefully chosen nifty colors and thistles that your other form
controls have. From the other side you're getting something much more
important than that: a non-compromised trust from your visitor.

All these considerations sound reasonably, but what about a different
point of view :

<snip>

Feci quod potui faciant meliora potentes...

You're getting more long-run troubles than short-time benefits, trust
me - but if it's indeed a question of life or death (or your New Year
bonus) then

<http://www.quirksmode.org/dom/inputfile.html>

[Victor]

You're getting more long-run troubles than short-time benefits, trust

me - but if it's indeed a question of life or death (or your New Year
bonus) then

<http://www.quirksmode.org/dom/inputfile.html>

Thank you VK for your compassion !

You know, I used just this technique - as described in the link - and
it brought me success -- however only with the FireFox ;-( The same
code does not produce the wanted result in the MSIE, that is the
problem...

Victor

[VK]

Victor wrote:

You know, I used just this technique - as described in the link - and
it brought me success -- however only with the FireFox ;-( The same
code does not produce the wanted result in the MSIE, that is the
problem...

The "zero opacity" trick from
<http://www.quirksmode.org/dom/inputfile.htmlworks for my IE 6 as
well. That must be again extra implications from your own code.
You have to take the sample exactly as it is and build the rest of the
form around it checking after each change.

P.S. Best of all of course to leave poor input="file" in peace ;-)

[Victor]

The "zero opacity" trick from

<http://www.quirksmode.org/dom/inputfile.htmlworks for my IE 6 as
well. That must be again extra implications from your own code.
You have to take the sample exactly as it is and build the rest of the
form around it checking after each change.

You were right, VK ! Thanks a lot !

P.S. Best of all of course to leave poor input="file" in peace ;-)

Cannot agree. This would be the worst case.
Surely, if there were no workaround, I would have to accept it. But
then I would create a decorative visual wrapper around it with a
mournful comment like this 'This way looks a secure browser. The
programmer does not bear any responsiblity for this owful lookout.'

Best regards and Happy New Year.

Victor