I have a text area form element with

'#ajax' => array(
  'event' => 'submit'
  'keypress' => TRUE,

Users can enter text, and it submits properly using AJAX when they press enter. But it also submits any time they press the spacebar - which is not the documented behavior, nor desired. I believe this bug is related to http://drupal.org/node/607240 but haven't tested to be sure.

If this is not a bug, then the documentation at http://api.drupal.org/api/drupal/developer--topics--forms_api_reference.... needs to be updated with the information that 'keypress' also binds to the spacebar.

Comments

mattyoung’s picture

Related to this? #607240: Usability: Allow AJAX behaviors to be triggered with spacebar

If so, maybe reopen that one with a "Need doc" tag?

threewestwinds’s picture

The behavior I'm observing is not what that issue was trying to accomplish.

The patch from #607240: Usability: Allow AJAX behaviors to be triggered with spacebar makes a button or image button submit on spacebar as well as enter. That's why I think this is related - my textfield is submitting on both spacebar and enter when it has 'keypress' => TRUE. But I didn't want to reopen that issue, since I'm not sure that it's related - I'll see if I can run some test and find out more tomorrow.

rfay’s picture

@threewestwinds, looking forward to your results.

Why would you set keypress = TRUE on a textfield?

threewestwinds’s picture

I wanted to catch a keyboard based submit. Someone types in something and presses enter, the page reloads rather than an ajax callback unless keypress is set. But with keypress set, the form also submits on a spacebar press. You can see the behavior I'm talking about at http://d7.threewestwinds.com/node/1 (the block on the left, "Votes").

Perhaps that's a bug as well - it certainly wasn't the behavior I expected, since pressing enter is a "submit" event on a single line text field.

threewestwinds’s picture

Status: Active » Needs review
StatusFileSize
new644 bytes

Ok, it was indeed the patch from the linked issue that causes this, though things have moved around a bit since it was filed.

I believe that the attached patch is the logic we want. A space should submit for usability purposes on every form element except a textfield. In that case, triggering a submit event just makes no sense unless the keypress is an enter.

rfay’s picture

StatusFileSize
new1.16 KB
new506 bytes

I think it needs to watch for textareas as well (as the attached patch).

Also attached is a testing module, spacebar_submit.

I tested this with IE 8 and FF 3.6 and it seems to all work fine, as we'd expect.

threewestwinds’s picture

I'm not sure how we want to handle textareas. There's no documentation at all as to the expected behavior, so first we have figure out what's supposed to happen.

'keypress' and 'event' => 'submit' don't make any sense at all for textareas, since there is normally no way to submit a textarea with the keyboard. It would make the behavior more consistent to submit on enter but not space, but it's still nonsensical to have a submit event for a textarea at all.

Actually, on second thought, there are a lot of form elements are not supposed to submit on space. Password, radio, textarea, textfield and checkboxes should not. For radio and checkboxes, space is the way you select an element, while password is basically just a textfield. Space-submit as a usability feature makes sense on all the others I didn't list.

rfay’s picture

Title: AJAX form submits on spacebar as well as enter » Textfield with #ajax['keypress'] activates on spacebar as well as enter

Just fyi, #ajax['keypress'] does not *submit*. It activates the behavior of the element. It can be made to submit (as demonstrated in the example module

An element can be made to submit by setting '#executes_submit_callback' => TRUE,

Your original report was about textarea :-)

The reality is that setting keypress = true messes up the behavior of checkbox. It works OK with select.

threewestwinds’s picture

Ah, cool. My brain was stuck in submit because that's what I was working with, but it makes sense that that's not necessarily the case.

I retract my previous comment then - your patch is good to go. And I really need to keep better track of textfield vs. textarea. Textfield was the one I meant.

rfay’s picture

If you think it's good, then go ahead and RTBC it :-)

threewestwinds’s picture

Status: Needs review » Reviewed & tested by the community

I didn't before (even though I did both review and test it) because it was very close to my patch. I think we're good to go, though.

webchick’s picture

Status: Reviewed & tested by the community » Needs work

There's A LOT of information in this issue that is not remotely captured in the code here. Looking at it out of context, I would have no idea why we special-case text and textarea there.

Let's get some added documentation. Though I'm wondering too if there's something more generic we could check for since right now this seems a bit brittle.

threewestwinds’s picture

I've started looking through the ajax.js internals to figure out exactly when this function is bound/triggered (and thus how to document it), but @rfay has a leg up on me, and might be better to write the documentation which I can then follow along with and verify. The translation of #ajax properties in PHP to JS is what I'm parsing through right now.

In short, I'll be happy to review any documentation, but it will take me a while to write any.

rfay’s picture

Actually, I think we can just add a discussion of *why* textfield and textarea are excluded and basically what that if statement involves.

The choices here have never been perfect (excluding checkbox, for example, where 'keypress' doesn't make sense.)

threewestwinds’s picture

I guess so - I was trying to figure out what situations the function gets called in. The name (keypressResponse) is misleading, since it's not involved in all keypress events (ie, autocomplete doesn't trigger it). I especially might expect a function with the documentation of "Handle a keypress" to be involved.

Webchick's spot on that there's a lot of information not captured in the documentation, and I think it'll take more than an extra line about why we special case textfields to catch it.

rfay’s picture

Status: Needs work » Needs review
StatusFileSize
new1.35 KB

This is the same patch as #6, rerolled with additional comments to explain what's going on.

threewestwinds’s picture

Status: Needs review » Reviewed & tested by the community

Looks good to me. I'm sure it's possible to over-comment code, but I haven't seen it yet.

webchick’s picture

Status: Reviewed & tested by the community » Fixed

Wow, nice job!

Committed to HEAD.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.