 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion GroupsGeneralPHPASPPerlColdFusionFlashHTML, CSS, ScriptsBrowsers |
Webmaster Forum / HTML, CSS, Scripts / JavaScript / December 2006Form submit per javascript
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 > // 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".  SignatureMatt Kruse http://www.JavascriptToolbox.com http://www.AjaxToolbox.com Matt Kruse schrieb: > > // 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 > 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 SignatureMatt Kruse http://www.JavascriptToolbox.com http://www.AjaxToolbox.com > [...] > 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). SignatureBart > Hi everybody! > [quoted text clipped - 15 lines] > > 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 > 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 >> Why do you have "document.forms['photoUpload'].elements['photo_1'].value" >> in [quoted text clipped - 9 lines] > > Victor I wasn't being picky. It's just that mixing name conventions causes a lot of headaches. > "Victor" <big.boss@chefmail.de> wrote in message > [quoted text clipped - 7 lines] > 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. SignatureBart >> "Victor" <big.boss@chefmail.de> wrote in message >> [quoted text clipped - 16 lines] > > 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.. 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 > 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. SignatureMatt Kruse http://www.JavascriptToolbox.com http://www.AjaxToolbox.com 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 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!!!!! SignatureEvertjan. The Netherlands. (Please change the x'es to dots in my emailaddress) > 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> VK schrieb: > > 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 [quoted text clipped - 14 lines] > 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: [quoted text clipped - 20 lines] > </body> > </html> Thank you VK for this small test listing. Regrettably, it could not bring me any further in solving my problem... Victor > > 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 [quoted text clipped - 9 lines] > > 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> > 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 > 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.html> works 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 ;-) > The "zero opacity" trick from > <http://www.quirksmode.org/dom/inputfile.html> works 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 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. SignatureEvertjan. The Netherlands. (Please change the x'es to dots in my emailaddress) > 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. > I am experiencing a strange - at least for me - phenomen. > I have a func containing the following code : [quoted text clipped - 11 lines] > > 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. SignatureBart |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.