Solved

Hidden form fields not being submitted?

Posted on 2003-12-09
22
1,144 Views
Last Modified: 2011-09-20
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
0
Comment
Question by:MannSoft
  • 5
  • 5
  • 4
  • +5
22 Comments
 
LVL 9

Accepted Solution

by:
pepsichris earned 125 total points
Comment Utility
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.
0
 
LVL 6

Author Comment

by:MannSoft
Comment Utility
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.
0
 
LVL 18

Assisted Solution

by:SquareHead
SquareHead earned 125 total points
Comment Utility
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>"
Next

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...
0
 
LVL 6

Author Comment

by:MannSoft
Comment Utility
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.
0
 
LVL 18

Expert Comment

by:SquareHead
Comment Utility
Then I'd have to agree with pepsichris -- hidden fields are treated no differently than other fields (that I'm aware of).
0
 
LVL 6

Author Comment

by:MannSoft
Comment Utility
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...
0
 
LVL 9

Expert Comment

by:pepsichris
Comment Utility
Do you have any encoding in your form?  IE6 uses a different default, so that might be it...?
0
 
LVL 6

Author Comment

by:MannSoft
Comment Utility
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.
0
 
LVL 9

Expert Comment

by:pepsichris
Comment Utility
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...!
0
 
LVL 7

Expert Comment

by:gam3r_3xtr3m3
Comment Utility
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>
0
 
LVL 6

Author Comment

by:MannSoft
Comment Utility
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.
0
IT, Stop Being Called Into Every Meeting

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

 

Expert Comment

by:x-cubed
Comment Utility
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?
0
 

Expert Comment

by:james_kyzo-com
Comment Utility
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 !
0
 

Expert Comment

by:x-cubed
Comment Utility
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.
0
 

Expert Comment

by:james_kyzo-com
Comment Utility
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.
0
 

Expert Comment

by:x-cubed
Comment Utility
Are you finding it applies only to a certain version of IE, or only on W2K3 machines?
0
 

Expert Comment

by:james_kyzo-com
Comment Utility
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.
0
 

Expert Comment

by:Darker1978
Comment Utility
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
0
 

Expert Comment

by:james_kyzo-com
Comment Utility
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 ?
0
 

Expert Comment

by:x-cubed
Comment Utility
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.
0
 

Expert Comment

by:james_kyzo-com
Comment Utility
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!
0
 

Expert Comment

by:ezlus
Comment Utility
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
0

Featured Post

Threat Intelligence Starter Resources

Integrating threat intelligence can be challenging, and not all companies are ready. These resources can help you build awareness and prepare for defense.

Join & Write a Comment

Suggested Solutions

Popularity Can Be Measured Sometimes we deal with questions of popularity, and we need a way to collect opinions from our clients.  This article shows a simple teaching example of how we might elect a favorite color by letting our clients vote for …
This article demonstrates how to create a simple responsive confirmation dialog with Ok and Cancel buttons using HTML, CSS, jQuery and Promises
In this Micro Tutorial viewers will learn how to create navigation buttons that change on rollover, using CSS (Continuation of the CSS Image Sprite tutorial) Create a parent ID for all the list items       - Specify position: absolute and display: block…
In this tutorial viewers will learn how to style transparent/translucent elements using alpha transparency in CSS Start with a normal styled element, such as a div.: Define its "background-color" property as "rgba (255, 255, 255, .5): The numbers in…

762 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

8 Experts available now in Live!

Get 1:1 Help Now