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?

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.

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:

    $captcha_sid = $form_state['clicked_button']['#post']['captcha_sid'];

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

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

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, ...)?

Has anyone encountered this with the 5.x version?

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.

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 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.

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.

@ArenCambre
thanks for nice solutions, helpful for me.. give me more time to do other..

---
My IT Blog

Finally! I found the trick to reproduce the problem.

The bug in Internet Explorer is explained here: http://style-vs-substance.com/form-submit-by-enter-key-and-internet-expl... (and probably elsewhere). The bug is not in Drupal or CAPTCHA, so fixing it in CAPTCHA is more a workaround, which makes this a feature request ;-)

The bug is only triggered if there is only one single text field in the form (text areas don't count as far as I observed). I was trying with a comment form, which had two (the title/subject field and the CAPTCHA response field), so I could not reproduce the problem. After disabling the title/subject field in the comment settings of the content type, I could reproduce it.

Now I can finally have a closer look.

Also note that the link mentioned above proposes its own workaround: add an extra dummy text field to the form and hide it (with CSS).

.. interesting! and really hard to track down ;)

Here is an updated patch

It solves the problem of the failing CAPTCHA after submitting with the enter key,
but the comment is not really submitted after all: it feels like it because there are no error messages, but you just get the original form back

This is a problem with Drupal , not with CAPTCHA because I could reproduce this behaviour with a comment form without a CAPTCHA:
* enable subject field for comments (and disable any CAPTCHAs)
* post comment as anonymous user in IE7: enter a subject, use tab to go to the comment text area, enter a comment, use shift-tab to go back to the title field and press enter
* result: the comment is not saved/added and you get the same form again without any error/warning messages
* when you press the save button with the mouse, the comment does get saved.

advseb/rewe: can any of you confirm this behavior?

So to conclude: the failing CAPTCHA is annoying, but it is not that bad because you get an error message that saving the comment did not work, with the fix of the attached patch (or other patches in this thread) it is worse because the comment saving fails without any warning/error message.

@ advseb and rewe: did you already have time to look at my remark in #31?

I'm planning to release a 6.x-2.1 version, and like to fix/close this issue before that. But, as discussed in #31, it seems that leaving the problem how it is (and not committing the patch) is the best solution at the moment. I'd like some feedback on this.

but I can just say that the patch we are using and which we submitted here is working on a large site

I know that the patches in this thread fix the problem of a failing CAPTCHA, that is not the issue anymore.
The real issue is however: is it possible to successfully save a comment with pressing enter in IE: please check that the comment is really saved, as you can get a false impression of a successful post because there is no error message.

So if you say that it "is working on your large site", do you mean:

1. you don't get failing CAPTCHAs anymore (the original symptom of this thread is cured)
2. you don't get failing CAPTCHAs anymore and comments are successfully saved too (the original symptom and the new problem described in #31 are gone)

Also relevant now: what version of Drupal are you using?

At advseb in #35: do you have both "preview" and "save" on first comment form or is preview mandatory?

Apparently you are talking about a live site, can you give the URL, so I can see the form (if you don't want to disclose it publicly, use my personal contact form http://drupal.org/user/41478/contact).

after some additional testing, it appears that the situation is not as bad as mentioned in #31,
the patch from #31 makes the source code better structured and avoids user unfriendly error message about CAPTCHA session for IE7 users,
so I decided to commit the patch from #31 (with tweaked doc/comments):
http://drupal.org/cvs?commit=319092

thanks all for testing

Just updated Captcha module to latest dev, but unfortunately the session ID problem remains - no IE - Mac OS FF, Chrome, Safari, Opera, and hitting the button. Overall discussion seems to be ended on december last year on separate post, but this still is active. What could be done to look through again?

No caching, yes reverse proxy is used, but without caching mechanism. No other caching or boosting modules.

[edit] Understood. The most close issue is here: http://drupal.org/node/632742, but still it has no solutions for reverse proxies (apache2) and caching thign. Thanx for heads up!

subscribe

@j2b (and @ianchan probably too): this thread is only about the submit-with-enter-in-IE7 problem.
Please do not start a discussion here about other problems, but continue the thread you refer to.

Although this issue has been fixed, and this is a different bug than #632742: Caching with Boost, Varnish, ... causes "CAPTCHA validation error: unknown CAPTCHA session ID", I think that it would be good to cross-reference these issues. I'm pretty sure that this is my issue (and not the Boost / Varnish issue that I cross-referenced), but I can't tell for sure, as I don't have the ability to test with IE6. I'm working on setting up that ability now.

@DavidWhite: I'm afraid there is little point in crossreferencing issues #534168: Submit with "return"/"enter" key in IE7 leads to failing CAPTCHA and #632742: Caching with Boost, Varnish, ... causes "CAPTCHA validation error: unknown CAPTCHA session ID". The former is about a client-side browser specific problem and the former is about a server-side caching issue.