[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
4 May
2009
4 May
'09
4:18 p.m.
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/
4 May
4 May
4:22 p.m.
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 <henning.sprang(a)gmail.com>wrote;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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki
Skype ID : wikibc
http://guillaumelerouge.com/
6:09 p.m.
New subject: [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
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/
6:44 p.m.
On Mon, May 4, 2009 at 6:09 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> 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
7:53 p.m.
New subject: [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
Henning Sprang wrote:
On Mon, May 4, 2009 at 6:09 PM, Sergiu Dumitriu
<sergiu(a)xwiki.com> wrote:
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 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. 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/
6:56 p.m.
Hi,
On Mon, May 4, 2009 at 6:09 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
Henning Sprang 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?
Guillaume
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/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki
Skype ID : wikibc
http://guillaumelerouge.com/
6:24 p.m.
New subject: [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
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
5667
days inactive
5667
days old
6 comments
4 participants
participants (4)
-
Guillaume Lerouge -
Henning Sprang -
Marius Dumitru Florea -
Sergiu Dumitriu