Hidden form fields not being submitted?


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.

Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Nope, hidden form fields are exactly the same as normal fields - they're visible in the html so not a security thing.

There'll always be (at least) one user who finds a way to screw things up, and it's a bitch when you can't find out what it is they've been getting wrong.

If the big red error message was sent from JavaScript then he may well have had that turned off.  The only other possibility is that the guy had an apostrophe in his name - I do, and that's caused me a few problems with various forms over the years.

If it's not the above, then personally I would be more than happy to blame him - his unwillingness to help out makes it seem more likely that it's his fault for some reason, but that's probably just me.

If you want, then post the address of the site and we'll have a look to see if anything may be slightly awry, but if 200 submissions have gone through then I wouldn't worry about it.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
MannSoftAuthor Commented:
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.
Here's one way (using ASP) to troubleshoot:

Add this to the code near the top of the page that receives the form fields:

if username = "theUser" then   '<-- "theUser" would be whatever the user's name is...

Dim x
For x = 1 to Request.Form.Count
    Response.Write Request.Form.Key(x) & " = "
    Response.Write Request.Form.Item(x) & "<br>"

end if

Then the user could cut and paste and send to you exactly what's being passed in the form submission...

Just an idea...
Big Business Goals? Which KPIs Will Help You

The most successful MSPs rely on metrics – known as key performance indicators (KPIs) – for making informed decisions that help their businesses thrive, rather than just survive. This eBook provides an overview of the most important KPIs used by top MSPs.

MannSoftAuthor Commented:
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).
MannSoftAuthor Commented:
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...?
MannSoftAuthor Commented:
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" />

<p>Textbox:<%=Request.Form("text1")%><br />
Hidden: <%=Request.Form("hidden1")%></p>
MannSoftAuthor Commented:
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 :-


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.


"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!

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

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.