Link to home
Start Free TrialLog in
Avatar of MannSoft
MannSoft

asked on

Hidden form fields not being submitted?

Hello,

I'm wondering if anyone has had any experiences where hidden form fields are not being submitted along with the rest of the input fields when a submit button is clicked?

I had a user who was having troubles registering at one of my signup pages.  After reviewing my code, I only see two possible reasons for the trouble.  Either A) he wasn't asnwering all the questions, and was ignoring the big, red error message being displayed, or B) the hidden form field required by the validation script was not being sent back with the rest of the data.

The guy has since become too frustrated and given up, so I can't use him to verify either of the possibilities, but I'm giving him the benefit of the doubt and assuming that he was not being shown any error messages since they should have been painfully obvious.

And in that case, that leaves me with the hidden form field question.  What I'm wondering is if there is maybe some obscure privacy tool that blocks hidden fields?  I'm having a hard time believing that one would exist since that would block access to many legitimate sites, but right now I'm grasping at straws.  And if it's not some sort of privacy tool blocking the hidden field, do you know of a browser setting that may have any effect like this?  Maybe when the form is being reloaded the page is being pulled from the cache and so the big red error that should be visible is not.  I've tried messing with settings, but as of yet haven't been able to reproduce the problem.

It should be noted that the form has worked fine for hundreds of other users, so I seriously doubt the problem is server side.  I've thought about just ignoring the problem since it's one in a couple hundred, but if it happens again in the future I'd like to know why.

Thanks,
Rick
ASKER CERTIFIED SOLUTION
Avatar of pepsichris
pepsichris
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of MannSoft
MannSoft

ASKER

Thanks for the feedback.

I know a hidden field should be treated normally, but there are probably some nuts out there that think of them as privacy issues because of their nature...they are hidden so the user is passing whatever information along without their knowledge.  I wasn't sure if someone had gone so far as writing a program to parse them out of form submissions.

And no, the error is output by an ASP script.  A large number of the users don't have javascript enabled, so rather than write both client side and server side validation I only bother with server side now.  It's less efficient since it takes a page reload to determine if input is good, but it's less hassle on my part.

I'd post the address, but it's for a private research project (which is what makes the problem somewhat important...it's an every user counts type of situation) so can't.

Thanks for replying anyway.
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
It's a great idea, and what my next step would have been, but the user is no longer interested in helping to solve the problem.  That's why I was hoping someone knew of something that would cause it, so I could duplicate it here and at that point I could use something like the above to see if my suspicion was true or not.
Then I'd have to agree with pepsichris -- hidden fields are treated no differently than other fields (that I'm aware of).
I just had another user report problems with the form, so hopefully they'll be more willing to help out.  I have a feeling the above code isn't going to help though.  I checked the IIS log files, and in "normal" cases, there is a GET for somescript.asp, and shortly after, a POST for somescript.asp.  In the case of these two people, there is a GET for somescript.asp, and then nothing.  

The users both said that after hitting submit the page reloaded with their input lost, so now does that sound like it may be a caching issue on their end?  From their user agent string I can see they are both using IE6 on WinXP so it's not like they are using antiquated software, but using the same browser/OS I wasn't able to duplicate the problem by messing with IE6's cache settings.

I've already run into cases of people running the Google toolbar which blocks calls to JavaScript's window.open, so maybe there is 3rd party caching software that could be interfering in this case?  I don't run any of those extra tools so I don't know what's available out there...
Do you have any encoding in your form?  IE6 uses a different default, so that might be it...?
What do you mean by encoding?  I've seen <form> tags that look something like this:

<form method="post" action="somescript.asp" enctype="application/x-www-form-urlencoded">

If you are talking about the enctype parameter, no I haven't specified one.  Both them and myself are using IE6 though, but I'm not sure of the exact version of them.  They may be a few patches behind or something.
There might possibly be a problem with that - I don't know too much about this area, but if your form uses GET, then try specifying the enctype="application/x-www-form-urlencoded"> as that was a problem with some versions of IE6, but that's the only straw I can grasp at for now - I'll give it some thought...

Incidentally, if it's POST then it won't be down to that.

And I still blame the users...!
yep, remove the enctype="application/x-www-form-urlencoded" if you form uses POST. since ASP and/or the browser automatically converts values on address bars and querystrings to return to the user and POST goes internally, urlencoding is supremely not recommended in post methods. but that shouldn't be the problem though, because any encoding it has, it should return a value. try debugging using different browser versions like:

main page
------------
<form method="post" action="somescript.asp" enctype="application/x-www-form-urlencoded">
<input type="text" value="im visible" name="text1" />
<input type="hidden" value="im hidden" name="hidden1" />
<input type="submit" />
</form>

somescript.asp
-----------------
<p>Textbox:<%=Request.Form("text1")%><br />
Hidden: <%=Request.Form("hidden1")%></p>
Sorry about the delay, I got busy with other things and didn't have a chance to work on this.

Since after reviewing the log files it looks like the problem is with the form being reloaded instead of submitted when the Submit button is clicked, I'm going to close this question and try posting a new one with a more appropriate subject line.

Thanks for trying.
I've been having similar problems with hidden fields using IE 6.0.3790 on Windows 2003 Server. As it was I had to change all the security settings to get my Javascripts going again, but I'm baffled by the 'disappearance' of these hidden fields.

I also found that IE 6 didn't like submitting forms to different ASPs
eg: form.asp set up to POST to savedata.asp resulted in savedata.asp having nothing posted to it.

I've fixed this by saving the data in the same page, but the hidden fields are still not being submitted.

Any ideas?
We're seeing somthing *very* similar, but not quite the same.

(don't laugh, this is true)

With IE6, when data is POSTed from a form to a CGI, if the user clicks the mouse button too quickly the form is submitted but not the data in the form. - none of it, no hidden fields, nothing.

I think it may be related to this :-

http://support.microsoft.com/default.aspx?scid=kb;en-us;185567

but I can reproduce it with *no* tables, just a straight form on a blank page - i.e. body, form, inputs, submit, end form.

The more data items in the form the more likely it seems to be to happen. I haven't been able to re-produce it with method=GET, but I'd hate to have to switch all my code !
Thanks for your comments James.
Upon further investigation it appears that none of the form fields are actually being submitted, if the form is set up to POST (a GET works fine). I don't have the form in a table.

I found that a recent "Critical Security Update" fixed the problem, to the extent that it goes alright for a while and then stops, and you need to close and reopen IE to get it submitting again. Whether it is a certain page that 'breaks' it, I'm unsure, but I'll keep investigating.

It sounds like your problem may be due to the fact that the form hasn't loaded completely before the submit button is clicked.
I've spent a lot of time researching and testing this bug and that's not it - honest - in fact, I found that if you leave the page for a few seconds, after it has loaded, it is more likely to create the problem. Also, interstingly, if it happens once it almost always happens, again right away, but third time it always seems to work correctly !

I know the MS report I quoted isn't related, but I think it is interesting to see that MS know that IE might submit the form without the data, and think that its OK - "This behavior is by design".

I am ABSOLUTELY convinced that this is a bug in IE6

To reproduce the problem do this, create a page with *just* a POST form with about 20 inputs and a submit, load the page, then click on the submit button by clicking the left mouse button for as short a time as you can. The way I do it is to hold the mouse down firmly with one hand and punch the left mouse button with one finger on the other hand - I know this isn't what my users are doing, but by doing this I can re-produce the problem about 1 in 10 times.

I have a Logitec PS/2 mouse, my collegue who has a wireless mouse can't re-produce the problem on his PC (identical hardware, O/S & IE) - weird eh ?

I'm actually developing a web admin interface for Linux, and half of our 8 beta sites have reported this problem. As you might imagine, when you are administering an O/S having a form submit with no data can really mess things up - Mozilla doesn't show this issue, but most people use IE.

I've bitten the bullet and changed everthing over to GET, but put it in a macro so I can switch back if this bug is ever fixed.
Are you finding it applies only to a certain version of IE, or only on W2K3 machines?
For the test, I was using the latest version of IE6 (patch up with all Windows Updates available) on Win98SE. Also, it was an SSL web site (Apache 1.3.28+mod_ssl) - I didn't test is on a non-SSL site as that wasn't useful for my application, but it is possible that the SSL is a factor.

We also did wonder whether the bug might not apply on NT/2K/XP because the mouse is managed very differently - That is, on 95/98 even when the O/S has crashed, and blue screened, the mouse still works, where as on NT the mouse will judder when the O/S is very busy.

This implies that the driver for the mouse on 95/98 is at a much lower level and so may be able to cause timing issues that it wouldn't be able to on NT based systems. Just a thoery. But seeing as this is obviously a very weird timing issue, it could be significant.

I will have to ask my users what platforms they were using.
Hello, we have almoust the same problem.

We want to open a new window with some parameters (which are proccesed before). For this we create an intermediar page with some hiden fileds (which will contain the required parameters) and the for is submitted (using "post"). In some cases (don't know when or why) the page is submitte without any value for the hidden fields.

It's happens rarely, but it's happen, we don't know why, we don't know how to reproduce it.
any sugestion is welcomed
use GET not POST - its the best solution I have found - so far.

Is your site SSL ? Do you get this with browsers other than IE6 ?

I found a Sun FAQ that said there was a "known" problem with SSLv3 and TLSv1 on MSIE - I don't think this gets us any closer to a long term solution, but its interesting.

http://www.sun.com/service/online.cgi/esm/faq.htm

"Q. Error: The page cannot be displayed. The page you are looking for is currently unavailable. The Web site might be experiencing technical difficulties, or  you may need to adjust your browser settings.

A. This is a known Internet Explorer issue. The way Microsoft Internet Explorer handles SSL version 3 and Transport Layer Security keep-alive connections cause interoperability problems with non-Microsoft web servers such as Sun ONE Web Server. When accessing a web server over SSL (https://) connections, Internet Explorer may inappropriately display error messages or blank pages."

"keep-alive" = HTTPv1.1 - so may be HTTPv1.0 would work ?
I don't believe that it is an issue with SSL or TLS, because I was having the problems over normal http:// connections.
I don't think keep-alive has anything to do with it either, because IE does correcty render the page it submits to, it just fails to send the data with the request.

I found the solution though: use a different browser. I found Mozilla Firefox to be quite good.
sadly that's not a solution I can give to my users - althought I have been using Mozilla for over a year now I can't force everybody else to!
Hi...

Looks like an IE security update created a new problem in IE -- when the server resets a connection the browser submits a blank header.  See the following for IE patches and server side workarounds

http://support.microsoft.com/?kbid=831167