Submit comments with Enter and use Shift+Enter for new lines #7252
Conversation
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Codecov Report
@@ Coverage Diff @@
## master #7252 +/- ##
============================================
+ Coverage 50.93% 50.93% +<.01%
Complexity 24710 24710
============================================
Files 1586 1586
Lines 94144 94145 +1
Branches 1364 1364
============================================
+ Hits 47948 47956 +8
+ Misses 46196 46189 -7
|
|
I still think we shouldn't do this, because on comments people should write longer, not more often... |
Seconded, I am not convinced of the change. |
Me neither; I am just granting @jancborchardt a wish :-P |
|
As commented on the other issue in Talk:
Also, we should have this consistent with the Talk app. |
|
(That is also, every time I used comments myself or had it tested by other people, when they used enter they were confused as to why it didn't submit. That's also why I asked for the change in Talk too. |
|
It used to be a two lines textarea, but then our designer wanted a self-growing one-line div-element. A single line suggests enter to be send. So yes, currently it does not match your expectations, because you changed one part but not the other. I still think we should just make the input-div a bit bigger then it is clear that enter will create new lines. It's the same on facebook. If you post your own item (big box with multiple lines height by default), enter means new line. On their chatty 1-line comments input, enter is submit. |
|
@danxuliu @MorrisJobke what about the failures? I'd lile to merge this. :) |
Basically it is complaining that no unit tests were added. And it is right :-O
Give me a second to add the tests ;-) |
When finding ".message" elements on "view.$el" the message area for the new comment form and all the comments were matched. Now the selector was restricted to match only the message area for the new comment form. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
That was a long second... :-P Anyway I could not add proper unit tests for entering a new line instead of posting a comment when shift+enter was used, as apparently the exact behaviour in that case depends on the browser. PhantomJS does not seem to handle key events on content editable divs, so the test only verifies that the default behaviour would have been executed when typing shift+enter. Better than nothing... |
|
I have noticed that pressing Enter when the autocomplete popover for mentions was shown caused the comment to be submitted instead of the mention to be completed; I have fixed that in the last commit. |
When the autocomplete popover is shown the At.js plugin listens on the message input field for key down events, and when Enter is pressed it adds the selected item to the message. However, as "_onTypeComment" also handles key down events for the message input field, when Enter was pressed the comment was submitted and At.js had no chance to add the item before that happened. Now when Enter is pressed and the autocomplete popover is shown the comment is not submitted, and thus At.js adds the selected item to the message as expected. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
danxuliu
force-pushed
the
send-comment-on-enter
branch
from
703eb69
to
9b1f3b9
Compare
|
I have amended the last commit to include unit tests too for pressing Enter when the autocomplete popover for mentions is shown (it was trickier than expected... but it is done now ;-) ). |
|
All CI failures are unrelated. |
Imported from nextcloud/spreed#474 as requested by @jancborchardt.