[xwiki-devs] hitting return inside the comment text input field after writing a little commit comment justr returns to the view and throws away my content
I just ran into this little, but very annoying problem, becaue I actually lost 15 minutes of editing: I entered some text in the page edit textfiled, but I also wanted to add a little save/commit comment. So I wrote some words into the the text input field, ad naturally, I hit return. The page view is shown, but all I entered into the text field is gone. Not exactly what I want when entering a save/commit comment, isn't it? Henning -- Henning Sprang http://www.sprang.de | http://lazyb0y.blogspot.com/
Hi Henning, could you please create a JIRA issue about this? It's the best way to notify the developers and the community of bugs you've been encountering. Please fill it with as many details as you can (XWiki version and setup, browser, browser version, detailed use case etc...). Thanks a lot in advance, Guillaume On Mon, May 4, 2009 at 4:18 PM, Henning Sprang <[email protected]>wrote:
I just ran into this little, but very annoying problem, becaue I actually lost 15 minutes of editing:
I entered some text in the page edit textfiled, but I also wanted to add a little save/commit comment. So I wrote some words into the the text input field, ad naturally, I hit return.
The page view is shown, but all I entered into the text field is gone.
Not exactly what I want when entering a save/commit comment, isn't it?
Henning
-- Henning Sprang http://www.sprang.de | http://lazyb0y.blogspot.com/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://guillaumelerouge.com/
Henning Sprang wrote:
I just ran into this little, but very annoying problem, becaue I actually lost 15 minutes of editing:
I entered some text in the page edit textfiled, but I also wanted to add a little save/commit comment. So I wrote some words into the the text input field, ad naturally, I hit return.
The page view is shown, but all I entered into the text field is gone.
Not exactly what I want when entering a save/commit comment, isn't it?
This is normal browser behavior. Hitting enter submits the form using the first submit button it finds. To avoid this, we can only do one (100% working) thing: reorder the buttons so that preview is the first one (or Save). -- Sergiu Dumitriu http://purl.org/net/sergiu/
On Mon, May 4, 2009 at 6:09 PM, Sergiu Dumitriu <[email protected]> wrote:
This is normal browser behavior.
I did not think about it yet, but you might be perfectly right. But it's defintely not what a user expects when doing exactly what I did.
Hitting enter submits the form using the first submit button it finds. To avoid this, we can only do one (100% working) thing: reorder the buttons so that preview is the first one (or Save).
I think that should definitely be done (going to file a Jira report as soon as I find some more time). Losing data is not really fun. I'm currently only testing xWiki with personal usage - I'm sure customers and coworkers will kill me if a tool I install for them behaves this way. Henning
Henning Sprang wrote:
On Mon, May 4, 2009 at 6:09 PM, Sergiu Dumitriu <[email protected]> wrote:
This is normal browser behavior.
I did not think about it yet, but you might be perfectly right. But it's defintely not what a user expects when doing exactly what I did.
Hitting enter submits the form using the first submit button it finds. To avoid this, we can only do one (100% working) thing: reorder the buttons so that preview is the first one (or Save).
I think that should definitely be done (going to file a Jira report as soon as I find some more time). Losing data is not really fun. I'm currently only testing xWiki with personal usage - I'm sure customers and coworkers will kill me if a tool I install for them behaves this way.
If they are not using IE6, then they can just hit the browser's Back button and get back the content. This isn't such a critical problem, since nobody reported it until now (I've known about it for a long time, but always considered it normal behavior). Guillaume Lerouge wrote:
This could trigger the more general question of action order in XWiki: sometimes the "do" action is on the left while the "don't" is on the right (for instance to post a comment the button in on the left while the cancel button is on the right), sometimes the "do" action is on the right and the "don't" on the left (as is the case when saving a page).
It would be much better if this ordering was consistent throughout XWiki.
As you can see from this page: http://doc.trolltech.com/qq/qq19-buttons.html#anextendedmessagebox the Windows ordering of such buttons usually is Ok / Cancel while the Mac OS X one is Cancel / Ok .
Given Sergiu's remark (the fact that upon hitting enter in a form field the action triggered is the one of the first button encountered), I'd say that we'd better have "Save" first in most cases -> it's better to save content as long as it can be deleted afterwards than the other way round (cancel first that leads to the data loss Henning experienced).
So my take on this issue would be that we should standardize buttons all around XWiki to have the Save / Preview / Cancel order for every post / save action (comment, page, blog post, form etc...)
WDYT?
Yes, I agree that we should do this standardization, but we should vote for the default order. I for one don't have a strong preference for either option. On one hand, the old interfaces have the DOs on the left, while on the other hand it is better to have them on the right, from the Usability PoV (the mouse usually comes in from the right side). New interfaces tend to switch to the right side (MacOS, Thunderbird, Firefox). I found a hack around this problem, we can put a disabled & hidden submit button before the Cancel button. It still counts as a submit button, but it prevents actually submitting the form when pressing enter (since it is disabled). It is a hack, because we're adding an element that shouldn't be there, and we're relying on CSS to hide it. We could put a meaningful text on it, like Wikipedia has "Please preview before saving", which will make it less of a hack. -- Sergiu Dumitriu http://purl.org/net/sergiu/
Hi, On Mon, May 4, 2009 at 6:09 PM, Sergiu Dumitriu <[email protected]> wrote:
Henning Sprang wrote:
I just ran into this little, but very annoying problem, becaue I actually lost 15 minutes of editing:
I entered some text in the page edit textfiled, but I also wanted to add a little save/commit comment. So I wrote some words into the the text input field, ad naturally, I hit return.
The page view is shown, but all I entered into the text field is gone.
Not exactly what I want when entering a save/commit comment, isn't it?
This is normal browser behavior. Hitting enter submits the form using the first submit button it finds. To avoid this, we can only do one (100% working) thing: reorder the buttons so that preview is the first one (or Save).
This could trigger the more general question of action order in XWiki: sometimes the "do" action is on the left while the "don't" is on the right (for instance to post a comment the button in on the left while the cancel button is on the right), sometimes the "do" action is on the right and the "don't" on the left (as is the case when saving a page). It would be much better if this ordering was consistent throughout XWiki. As you can see from this page: http://doc.trolltech.com/qq/qq19-buttons.html#anextendedmessagebox the Windows ordering of such buttons usually is Ok / Cancel while the Mac OS X one is Cancel / Ok . Given Sergiu's remark (the fact that upon hitting enter in a form field the action triggered is the one of the first button encountered), I'd say that we'd better have "Save" first in most cases -> it's better to save content as long as it can be deleted afterwards than the other way round (cancel first that leads to the data loss Henning experienced). So my take on this issue would be that we should standardize buttons all around XWiki to have the Save / Preview / Cancel order for every post / save action (comment, page, blog post, form etc...) WDYT? Guillaume
-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://guillaumelerouge.com/
Hi, I can reproduce it on the trunk, independent of the editor or page syntax. Pressing enter on the comment text field seems to act like a cancel. I just tried with an new page. Pressing enter takes me back to the "You can edit this page to create it." message. Can you open a jira issue? Thanks, Marius Henning Sprang wrote:
I just ran into this little, but very annoying problem, becaue I actually lost 15 minutes of editing:
I entered some text in the page edit textfiled, but I also wanted to add a little save/commit comment. So I wrote some words into the the text input field, ad naturally, I hit return.
The page view is shown, but all I entered into the text field is gone.
Not exactly what I want when entering a save/commit comment, isn't it?
Henning
participants (4)
-
Guillaume Lerouge -
Henning Sprang -
Marius Dumitru Florea -
Sergiu Dumitriu