Submit with "return"/"enter" key in IE7 leads to failing CAPTCHA

I don't have internet explorer, so I can't test/debug this.
But I've heard of problems with IE and submitting a form with enter before (e.g. see http://www.google.com/search?q=internet+explorer+enter+key+form, #194327: _form_builder_ie_cleanup not working -search submission)

In any case: it's technically not a bug in the CAPTCHA module as far as I know, but in Internet Explorer and it should be fixed/worked around in the Drupal Form API, I think. Which version of Drupal are you using?

Seems like a character is added by IE7 to the solution entered while pressing the return key.

can you confirm this? what character is added?

I am using the latest Drupal 6 version. How can I find out which character is added to the input field?

One way is enabling the logging of wrong answers (there is a checkbox on the CAPTCHA admin page for this) and looking at the watchdog log of your site. However I don't expect this to return reliable info.

A better way is hacking the CAPTCHA module and inserting code to inspect the answer directly, but I don't know if you are familiar with this.
I'll try to do it myself when I have access to a setup with internet explorer.

I can change the module and add a watchdog entry. Just give me an idea where in the code I should add it.

The problem still exists with RC3.

I forgot to mention that I get the message "CAPTCHA test failed (unknown csid)" as described in this duplicate bug report: http://drupal.org/node/571886

I tried again with the current 2.x-dev release (2009-09-11) and the problem still exists. I get the following message in the watchdog list:

Message CAPTCHA validation error: unknown CAPTCHA session ID (NULL).
Severity error

The problem occurs with image_captcha and math_captcha.

Here are some more debug outputs, which might give more insights what is going wrong. I added them to the function: function captcha_validate($element, &$form_state)

I added the following statements:

In case I confirm in IE the form with RETURN key, I get the following output:

captcha_info: array ( 'form_id' => 'comment_form', 'module' => 'captcha', 'type' => 'Math', 'captcha_sid' => '44', 'solution' => '5', )
captcha_response: '6'
form_state: NULL <-----!!!

In case I confirm in IE the form by clicking on the publish button, I get the following output:

captcha_info: array ( 'form_id' => 'comment_form', 'module' => 'captcha', 'type' => 'Math', 'captcha_sid' => '44', 'solution' => '2', )
captcha_response: '5'
form_state: '44'

If I do the same again using Firefox 3.5, form_state is set correctly in both cases.

Question: Why don't you use 'captcha_sid' field from captcha_info? It seems to have the correct value in all cases?

Answer by myself: I tried using captcha_sid from captcha_info. In case I confirm the form using the button it works as expected. In case I hit RETURN, the same problem as before. It seems that at the moment the query looking for the solution in captcha_validate is issued, no entry exists if the form was submitted in IE using RETURN. The problem is that in captcha_process() function also the unset fields are used. Here, a solution might be something like:

Please let me know if I should additional debug statements.

at advseb in #8: very nice you're diving into the code to tackle this sucker. I don't have IE7. I'm on OSX and Linux and I only get up to IE6 with ie4linux and ie4osx. The problem is I can't reproduce this issue on IE6, is this issue IE7 specific?

Anyway, I'm a bit confused about your experiments in #8:
first you say that $captcha_info['captcha_sid'] is always available (even for IE+entersubmission), this value is set in captcha_process() and comes from around line 200 in captcha.module:

So, if it's available the above statement worked and the values were set.

But then you say

in captcha_process() function also the unset fields are used

So, could you look into this?

Another thing about your suggested solution is that $form_state['buttons'] does not always exist. E.g. for a CAPTCHA on the comment form, there is a $form_state['buttons'] , but for a CAPTCHA on a node form there is no $form_state['buttons'] , only $form_state['clicked_button']

thanks for looking into this

I don't have access to the test systems on weekend, so no real answer possible before Monday. But I was wondering why it is so hard to embed those values in forms. I saw that you are using hidden fields. Aren't there easier ways to get those values? Have you looked, e.g., how the Mollom modules does it?

Anyway, I'm a bit confused about your experiments in #8:
first you say that $captcha_info['captcha_sid'] is always available (even for IE+entersubmission), this value is set in captcha_process() and comes from around line 200 in captcha.module:

The $captcha_info structure is always set, because if you can't get a valid session id in captcha_process, you create a new one. The bug is really in captcha_process(). Probably, it will need a more finetuned way to get the form values in the different cases (node form, comment form, preview, etc.).

But I was wondering why it is so hard to embed those values in forms.

The embedding is not hard. The difficulty is getting the right info back from the client/browser.

I saw that you are using hidden fields. Aren't there easier ways to get those values?

I'm open for suggestions.
In any case: it's best to keep the CAPTCHA solution on the server (only send the challenge to the client) and because HTTP is stateless, you need some sort of session concept to make CAPTCHA work.
In CAPTCHA branches 5.x-x.x and 6.x-1.x, we used the $_SESSION variable for this end, but this solution suffered from some problems (most importantly: cookies are required and the session table could grew very large because every anonymous visit was stored).
In CAPTCHA 6.x-2.x we do our own session housekeeping to avoid polluting the sessions table and do not require cookies. The CAPTCHA session ID is the key to pair challenges (send to the client) with solutions (kept at server). This CAPTCHA session ID is send with each CAPTCHA protected form as a hidden field.

Mollom uses the same principle with a hidden session ID field as far as I know.

There is are simpler keys to pair challenges with solutions, like the IP-address of the user to name something (which would not require a hidden field). But then you can only support (at most) one form per user at a time. So no support for multiple forms per page or multiple open forms per user in parallel (e.g. a user opening several post forms in separate tabs). And then we're still assuming that IP addresses are unique per user, which is not always true today.

Anyway, if you have suggestions: shoot

hi, I'm a co-worker of advseb's -

here's what we did to fix this issue for now:

scenario: using the internet explorer and submitting a capture-enabled form by hitting the enter key rather than clicking submit or preview or whatever

symptom: the sub array ['clicked_button'] is not created which is why some checks in the functions captcha_process and captcha_validate fail and ultimately cause the overall capture solution to fail because a new csid is created every time the function captcha_process is called

solution: we added some logic that also checks the ['buttons'] sub array because it also has the required csid etc. in it

best regards

Attachment	Size
2009.09.15-captcha.module.patch	2.88 KB

Thanks for the patch.
I can't try it out for the moment however, so I just gave it a quick look.

I think this special case code should be refactored to a function, e.g. captcha_get_posted_captcha_sid($form_state) for better code reuse and to keep the pollution of the normal code low.

Did you already tried if it works with different forms (e.g. comment form, node form, user login form, user registration form, ...)?

We are using it on the user registration form and the comment form. We have not tried the other forms.

Has anyone encountered this with the 5.x version?

Is version 6-2.0 containing the fix?

Is version 6-2.0 containing the fix?

No,
the current patch still has "needs work" status (see #14) and it is not confirmed it fixes it for all use cases (on comments, on node forms, on login forms, with extra AJAX in the mix, etc).

Getting a final 6.x-2.0 out of the door was long overdue and had a higher priority than this (non critical) issue.
Moreover, now that we have 6.x-2.0 out, we can get more eyes on this issue.

It should be fixed for CAPTCHA 6.x-2.1, though.

Attached is a new version of the patch. It was created against 6.x-2.0 release branch. We also did the refactoring you suggested (moving code in an extra function). We are using the solution for comment and user registration forms and the patch is deployed on a large community already.

Attachment	Size
2009.10.01-captcha.module.patch	3.64 KB

Thanks for the refactored patch,
I didn't have time yet to give it a closer look

but I wonder if the refactoring couldn't be pushed further, e.g. to put the stuff about $posted_form_id also in the refactored function

I suggest to not refactor it in a function at the moment, because this function would only be used at one point in the code. There is a rule saying you should not refactor something until it is really needed.

I disagree,
refactoring is not only useful for fighting code duplication, it can also help make the code cleaner/better readable and maintainable.
Moreover, I think you can do the refactoring so it can be used in different places.
See attachment for what I mean.

Attachment	Size
534168_IEenter_03.patch	4.63 KB

Ah ok, you are refactoring both things into one function. That is ok I think.

Hi,

I recently played a bit with IE7 to work on this issue, but I couldn't reproduce the problem.
I tried on comment form, user login block, user login page, forum post form, but all worked as expected when submitting with the enter key. (both the numpad enter key and the normal enter key)

Do you have a live site with the problem?

(Comment edited because it's not germane to this issue.)

If you enable CAPTCHA module and have caching enabled, anon users may not see CAPTCHA features on comment submission page and may get this error on comment review page: CAPTCHA validation error: unknown CAPTCHA session ID. Contact the site administrator if this problem persists.

Solution provided in next comment. It's a caching issue.

At Aren Cambre in #25: I'm afraid you are talking about a different issue here. This issue is specifically about posting a form in IE7 with the enter key instead of pressing the submit button with the mouse. You say you can "kind of duplicate" the issue, but you never mention using the enter key or submit button. So if it's not about enter key/submit button, please open your problem as a separate issue, to keep the discussion clean.

That being said, a possible cause of your problem is caching: if a page with form is cached before the CAPTCHA module is enabled and can do its thing, an anonymous user will get the form without CAPTCHA and posting will fail (with the error message you mentioned). I would suggest to clear (or temporarily disable) the page cache. If that does not work, please open a separate issue as I mentioned above.

We have a live site with this problem, but we are using our fix now since several months and it works fine...