Submit forms with CTRL+Enter in textareas

[shesek]

Can you add support for submitting forms when pressing CTRL+enter in a textarea, in the same way they're submitted when enter is pressed in a regular input box?

Its a nice feature that makes it easier to submit forms, as no mouse or tabbing is needed (when I found out Eclipse supports that when writing commit messages, I thought it was the best invention since sliced bread! ), which is quite easy to implement using jQuery:

$('textarea').keypress(function(e){
    if (e.ctrlKey && e.keyCode == 13) {
        $(this).closest('form').find('input[type=submit][name=submit]').click();
    }
});

This snipped would click an input with name=submit and type=submit (the one that submits the changes, without a preview) in the same form as the textarea, whenever CTRL+enter are pressed in a textarea.

If you feel it'll make people submit tickets without previewing them first, it can be changed to only send ticket comments directly and use the preview for other forms:

$('textarea').keypress(function(e){
    if (e.ctrlKey && e.keyCode == 13) {
        $(this).closest('form').find('input[type=submit]'+(this.id==='comment'?'[name=submit]':'')).eq(0).click(); // When it isn't textarea#comment, the first submit button is used (which is the 'preview' button)
    }
});

P.S.

When I first tried to implement this on my Trac, my first attempt was with $('textarea').closest('form').submit(); which didn't work as the name used for the submit button ​is considered unsafe. This is also mentioned on ​jQuery documention, and there's ​DOMLint to check for that kind of issues.

Yes, I was also surprised that 'submit' isn't a valid name for submit input and I'm not quite sure if it should really be fixed.

[Remy Blank]

Nice idea. Full (tested) patch welcome.

[shesek]

I would happily write a patch, except that I don't really know how to write one :-)

And besides, all that's needed is adding that javascript snippet to chrome/common/js/trac.js, no server-side code or any other modifications.

If its really needed, I will go learn how to write patches and write one that appends that javascript code to trac.js. Just let me know.

[Remy Blank]

Adding the JavaScript snippet is quick indeed. What takes more time is testing it thoroughly, and going through all the pages in Trac containing <textarea> and figuring out if the new behavior works and makes sense there. We wouldn't want a destructive operation to be triggered too easily with such a shortcut, for example.

Creating a patch is actually surprisingly easy.

[shesek]

What about adding support for ticket comments only? That's the place I think it'll be the most useful anyhow:

$('form[action*=trac-add-comment] textarea#comment').keypress(function(e){
    if (e.ctrlKey && e.keyCode == 13) {
        $(this).closest('form').find('input[type=submit][name=submit]').click();
    }
});

Is that acceptable, or you think it should be added to other places too? If it is, are there any tests you think I should make?

[Remy Blank]

Replying to shesek:

What about adding support for ticket comments only?

Sounds like a good first step. Does it work consistently with the major browsers (Firefox, Chrome, Safari, IE, Opera)?

[shesek]

It was missing support for the form used when editing comments (only worked when posting new comments) and should've been called on the DOMReady event. This is the new code:

$(function(){
	$('form[action*=trac-add-comment] textarea#comment, form#trac-comment-editor textarea[name=edited_comment]').keypress(function(e){
		if (e.ctrlKey && (e.keyCode == 13 || e.keyCode == 10)) {
			$(this).closest('form').find('input[type=submit][name=submit],input[type=submit][name=edit_comment]').click();
		}
	});
});

This was tested on Chrome 6.0.472.62, Firefox 3.6.8, Safari 4.0.4, Opera 10.10 and Internet Explorer 8.

Some of the browsers are a bit out-dated, but its a pretty simple code that's based on jQuery, so I don't think there should be any issues on other versions. However, you never know with IE and I don't have IE6/7 installed… any chance someone can check it?

---

I do think a better approach that eliminates the need for those long selectors is adding an 'ctrl-enter' class to <input> submit elements that should be clicked when CTRL-enter is pressed in a textarea under the same form.

The edit comment input, for example, would be <input type="submit" name="edit_comment" class="ctrl-enter" … />. Than this javascript can be used to automatically detect it:

$(function(){
	$('form:has(input[class~=ctrl-enter]) textarea').keypress(function(e){
		if (e.ctrlKey && (e.keyCode == 13 || e.keyCode == 10)) {
			$(this).closest('form').find('input[class~=ctrl-enter]').click();
		}
	});
});

I personally really prefer that approach, but than its not a 'pure' javascript solution, as it requires a (minimal) HTML change. However, the JavaScript code it much cleaner and its much easier to decide which forms/inputs use that behavior. When a new form is created that should use it, it doesn't require any JavaScript modification.

I haven't tested the second version yet, but if you agree on using that approach I'll gladly set-up my local Trac to use it and see if it works well on all major browsers.

[Remy Blank]

Replying to shesek:

I do think a better approach that eliminates the need for those long selectors is adding an 'ctrl-enter' class to <input> submit elements that should be clicked when CTRL-enter is pressed in a textarea under the same form.

That's what I was thinking when I wrote "Full (tested) patch welcome" above. It often happens that while implementing some functionality, new ideas pop up, often generalizations of the original idea. That's an important part of adding new functionality, which doesn't happen if you just submit a "just add this here" proposal (in addition to the testing, and the browsers you use are fine).

So yes, in this case the behavior can probably be nicely generalized, and used in other locations, too (milestones? admin panels?). And if you go that way, please make sure you submit a proper patch, as this makes integration and testing much easier.

About IE, we don't really care much about IE6 anymore. And you can test IE7 using IE8 by switching to "IE7 mode" (press F12, then select "Internet Explorer 7" under "Browser Mode" at the top.

[Christian Boos]

I think it's fine to submit wherever we have an automatic preview. For other places, we should rather trigger the preview instead of the submit. Hence the ctrl-enter approach should be preferred, so that we have full control about which input gets fired. Maybe the class name could be something like quicksubmit or something more neutral than ctrl-enter, in case we decide to change the mapping to some other key combination?

[shesek]

Added CTRL-enter submission to ticket updates

[shesek]

attachment:submit-form-ctrl-enter.diff​​ works as described at comment:6 second option and tested on Chrome 6.0.472.62, Firefox 3.6.8, Safari 4.0.4, Opera 10.10, IE 8 and IE7 7 mode under IE8.

Some JavaScript code was added to trac.js to find inputs with a 'quicksubmit' class. That class was added to the 'submit changes' buttons in the ticket comment/update form and the ticket comment modification form. Sorry it took some time, I was away for Sukkot :)

Replying to cboos:

Maybe the class name could be something like quicksubmit or something more neutral than ctrl-enter, in case we decide to change the mapping to some other key combination?

I did change it to quicksubmit, as I find it nicer than 'ctrl-enter', but ctrl-enter is the standard so I think that's the shortcut that should be used.

[shesek]

Shouldn't 'accept' change the owner to the same value as what I entered under 'author'?

[Remy Blank]

Patch available → trunk

[shesek]

Added 'quicksubmit' to preview buttons in ticket creation and wiki page form

[shesek]

Sorry, ignore the last diff file (attachment:submit-form-ctrl-enter-2.diff​), I haven't tested it on ticket pages before uploading this (as I thought the changes were minimal). Will upload a working fully tested patch shortly.

[shesek]

A fixed fully tested version of attachment:submit-form-ctrl-enter-2.diff​. Uses 'quicksubmit' class on ticket creation preview button, wiki page preview button, ticket update submit changes button and ticket comment modification submit changes button.

[shesek <nadav+shesek@…>]

Adding 'patch' keyword so it'll hopefully be noticed by someone at TracDev/ToDo… not quite sure if the last patch is acceptable or requires more fixing

[Remy Blank]

Specify preview or submit per-textarea.

[Remy Blank]

The patch works great. One detail though, related to comment:8. When editing a ticket, the current patch sets all <textarea> fields to submit changes (instead of previewing) on CTRL+Enter. However, only the comment field has an automatic preview, the description doesn't.

Ideally, CTRL+Enter in the comment field should submit, and should preview in the description field. How about using two different classes "quicksubmit" and "quickpreview", and marking the <textarea> tags with those classes as well?

9638-preview-submit-r10407.patch​ does exactly that. Thoughts?

[Christian Boos]

Maybe we should have a way to know whether there's an automatic preview active, and make the behavior of CTRL+Enter depend on that. For example, on a Wiki page in side-by-side edit mode, with the patch we have quickpreview behavior, which is not that useful if automatic preview is already active, but would be quite handy otherwise. Patch follows.

[Christian Boos]

applies on top of 9638-preview-submit-r10407.patch​

[Christian Boos]

While uploading patch… thought we could add this feature for the Attachment description <input> as well.

[Christian Boos]

Updated patch adds support for trac-quickedit and trac-quicksubmit for <input> elements. Also fixes the glitch 's/edit/preview/' in determining the action.

[Christian Boos]

applies on top of 9638-preview-submit-r10407.patch​

[Remy Blank]

A simple "Enter" in the attachment description <input> is enough to submit the form, no need for CTRL+Enter.

I'm not convinced linking the automatic preview and the quick-edit functionality is a good idea. I would rather keep them separate and be allowed to choose per-textarea if it should trigger a preview or a submit. Feels simpler to understand when reading the template.

[Christian Boos]

Replying to rblank:

A simple "Enter" in the attachment description <input> is enough to submit the form, no need for CTRL+Enter.

Right ;-)

I'm not convinced linking the automatic preview and the quick-edit functionality is a good idea. I would rather keep them separate and be allowed to choose per-textarea if it should trigger a preview or a submit.

Well, if both deal with previewing, they'd better do it in consistent and useful way. If we don't have this consistency (CTRL+Enter ⇒ submit if auto-preview, preview otherwise) then it's not going to be easy to tell from a user perspective whether you'd get preview or submit on doing CTRL+Enter. So failing that, we should better always have CTRL+Enter do a submit.

[Remy Blank]

Replying to cboos:

Well, if both deal with previewing, they'd better do it in consistent and useful way. If we don't have this consistency (CTRL+Enter ⇒ submit if auto-preview, preview otherwise) then it's not going to be easy to tell from a user perspective whether you'd get preview or submit on doing CTRL+Enter. So failing that, we should better always have CTRL+Enter do a submit.

Oh, nothing against having that consistency. I just meant to achieve it "by hand" by setting the relevant class explicitly rather than having it done automagically. It doesn't make a difference for the user, but it's more explicit for the poor developer who is trying to make sense of the templates (that is, me in two months ;).

[Christian Boos]

Replying to rblank:

Replying to cboos:

Well, if both deal with previewing, they'd better do it in consistent and useful way. If we don't have this consistency (CTRL+Enter ⇒ submit if auto-preview, preview otherwise) then it's not going to be easy to tell from a user perspective whether you'd get preview or submit on doing CTRL+Enter. So failing that, we should better always have CTRL+Enter do a submit.

Oh, nothing against having that consistency. I just meant to achieve it "by hand" by setting the relevant class explicitly rather than having it done automagically.

But "by hand" (read statically) won't work, as having auto-preview is a dynamic thing…

[Remy Blank]

Replying to cboos:

But "by hand" (read statically) won't work, as having auto-preview is a dynamic thing…

Sure it will, you just have to use the same condition involving auto_preview_timeout in the class expression.

[Christian Boos]

Replying to rblank:

… you just have to use the same condition involving auto_preview_timeout in the class expression.

That would be just another way to tie the two things together… In addition, you'd need to make that auto_preview_timeout value available to Genshi (currently it's added as a Javascript data). All of this is certainly doable, but wouldn't that be more verbose and error prone than a Javascript solution?

[Remy Blank]

I hadn't thought about auto_preview_timeout being JavaScript-only. Anyway, it's not that important, just do as you prefer.

[Remy Blank]

Preparing for 1.0.

[Christian Boos]

May still be done for 1.0.

[Ryan J Ollos]

Narrowing focus for milestone:1.2. Please move ticket to milestone:1.2 if you intend to fix it.

[Ryan J Ollos]

Milestone renamed