Unwanted Item Validaton

[Phil -- wbtc.fr --]

Hello guys,

on 510-RC1, when you create any kind of item, for example a new section, if you press "enter" after entering the name, for example, which is maybe one of the more common behavior for any office user, the form reload with all fields blank.

Pressing enter should perform the same action as "save", or do nothing, but not clear all :D

Phil.

[Alexander Obuhovich]

I disagree, since pressing enter in textarea should place enter there, not make form submit. Also enter pressing should act like a TAB in my opinion.

--
You received this message because you are subscribed to the Google Groups "In-Portal Bugs Team" group.
To post to this group, send email to in-port...@googlegroups.com.
To unsubscribe from this group, send email to in-portal-bug...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/in-portal-bugs?hl=en.

--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com

[Phil -- wbtc.fr --]

if you try to type in in a text field, such as Name, it breaks the process.

Acting as "Tab" is a good idea too

2010/6/28 Alexander Obuhovich <aik....@gmail.com>

[Dmitry Andrejev]

I agree with issue reported by Phil.

It's not good to reload the page on the Enter.

I suggest we perform onSave action (same as I clicked Save) with exception it would ONLY apply to INPUT fields with type TEXT. All other fields are safe - have NO any sort of actions.

In case if it's too hard to implement - let's at least make so it doesn't refresh (or do) anything.

DA.

[Alexander Obuhovich]

That ENTER stuff only happens (in Firefox at least), when you have only ONE input field on form and you hit ENTER while typing text in it.

This is browser auto-form-submit feature and there are not special logic in that. I've managed to reproduce it on group editing page.

To overcome such nasty effect we usually add hidden input field on each form, so browser won't react on ENTER in described way. But since there are no much forms with only one input field in administrative console, then there was no need for that.

Since all edit forms should use "inp_edit_filler" block on them to fill empty space beneath controls, then we could add that hidden input there and see how it will end up.

I've attached patch with proposed fix. Since it will have minimal impact on existing functionality, then I suppose, that it will be used at the end.

What's your opinion on that matter?

[Phil -- wbtc.fr --]

if this is the auto-complete-form browser function, then what does the "save" button does?
If it does the same as "save button", we would't have any problem, as it would either save the form or display error message for required field. Am I wrong?

2010/7/23 Alexander Obuhovich <aik....@gmail.com>

[Phil -- wbtc.fr --]

and there's no way to avoid this auto-action? as you said, is the action do nothing, it'd be ok, no?

2010/7/23 Alexander Obuhovich <aik....@gmail.com>

That browser function doesn't save anything, since "Save" toolbar button also closes window if no errors are found on the form. That browser function just submits form data to server without giving any particular action to apply to sent data.

[Alexander Obuhovich]

If you understood my previous post (where I've attached patch), then it actually effectively cancels browser auto-submit on enter action. Also in that post I've asked if it's ok to stick to that solution, but you obviously understood it differently and therefore asked next questions.

[Phil -- wbtc.fr --]

ok, I'll go to sleep :-)

2010/7/23 Alexander Obuhovich <aik....@gmail.com>

[Alexander Obuhovich]

So what's here, we'll stick to my proposed patch or will develop another solution?

[Phil -- wbtc.fr --]

Cancelling autosubmit seems the best solution to me, this way we don't disrupt the standard process of clicking on save button.

2010/7/29 Alexander Obuhovich <aik....@gmail.com>

[Alexander Obuhovich]

Task created: http://tracker.in-portal.org/view.php?id=815

Ready for testing.