-
Notifications
You must be signed in to change notification settings - Fork 7.6k
prevent event from being used to enter a newline into editor #7493
Conversation
@njx Per earlier conversation, I think the reason this doesn't crop up in our dialogs much is that most of our dialogs fail to re-focus the editor when they're being closed -- so the subsequent keyup doesn't go the editor, it just goes off into space. Whenever we fix our dialogs to behave better I think we'd need this fix for core too :-) |
@@ -153,6 +153,8 @@ define(function (require, exports, module) { | |||
// Enter key in single-line text input always dismisses; in text area, only Ctrl+Enter dismisses | |||
// Click primary | |||
$primaryBtn.click(); | |||
// prevent event from being used to enter a newline into editor | |||
e.preventDefault(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes sense, but it seems like we should do this in all the other cases where we handle the keypress as well. For example, if you do Quick Edit on a tag, then open your dialog and hit Esc, I bet it falls through to the editor too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also wonder if we should do stopPropagation()
in these cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
stopPropagation()
didn't help in my case (it was my first guess) but preventDefault()
did ... I didn't find any weird stuff going on in my code on first look.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I don't think it's required for this case, but it probably makes sense in general since someone else might attach an event handler and we should act here like we've handled it. (I guess there's a question of why we don't just do that in any case in the global keydown hook stuff when a hook returns true.)
What do you think about adding it to the other cases in this method (Esc, etc.)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(To be clear, I mean - what do you think about preventing default in the other cases? Does the Esc case I mentioned above occur with your extension?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, in my opinion we should preventDefault
and stopPropagation
always when we use the event to trigger another event with methods such as .click
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it makes sense to do it in basically all the cases where handling the event causes the dialog to dismiss (which I think is pretty much all the arms of the if statement, except maybe for the TAB case) - it's not so much about triggering another event, but the fact that the keyup goes to the main editor after the dialog is dismissed.
I guess I'm suggesting that you go ahead and fix those other cases as part of this pull request, instead of just fixing the Enter case (since I think other cases like Space and Esc could affect you as well anyway). If you don't have time, let me know and I'll take a stab at it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm quite busy this week before vacation and you probably know more about this than I, so feel free.
Sorry this missed release 39. I'm tagging it for release 40 so I don't forget about it. |
…o handle the keyup
@zaggino Just pushed an update to this that does the stop/preventDefault in more cases. Would you like to review it? I did some testing with various dialogs in brackets-git as well as the file filters dialog and everything seems to be working okay, but it could probably use more testing. @peterflynn FYI - do you think this is reasonably safe? |
@njx Writing spaces into the Extension Manager search box is very laggy with this PR. |
@SAplayer Are you sure that's specific to this branch? Any lag there is probably from the actual search through the large number of extensions taking time, not from the event handling. I don't notice any difference between master and this branch in that regard. |
Oh, you're right. I'm sorry. |
Change Milestone to Release 0.41 |
Assigning to @zaggino to review my changes to the original PR. |
And I'm not 100% sure whether to use |
@zaggino Interesting - this looks like a bit of a difference between Mac and Windows. In native Mac apps (if "Full Keyboard Access" is on, so you can tab to buttons), Enter always activates the default button even if a different button has focus - you have to hit Space to activate the focused button. On Windows, when a button is focused, both Enter and Space activate it. (The Windows behavior actually has a slight added nuance. If a non-button control in the body of the dialog is focused, then the original primary button has the "primary button" highlight, and hitting Enter will activate it. But if a button control anywhere in the dialog is focused - regardless of whether it's a dismissal button - then that button control gets both the focus look and the "primary button" look, making it clearer that both Enter and Space will activate it. So the "primary button" highlight actually jumps around as you tab through buttons in dialogs, then returns to the original primary button whenever a non-button is focused.) I could imagine keeping the original behavior on Mac and changing it for Windows only - though I don't really know how many people are familiar with this nuance on the Mac (perhaps some people might turn it on for accessibility reasons). Or we could just decide not to deal with all these nuances and just keep what you have on both platforms (i.e., if the focused element is a button, Enter always activates it, otherwise activates the original primary button, and we don't worry about moving the "primary button" highlight around). @larz0 do you have an opinion? |
@njx |
Sounds good - I will try to look at your most recent change tomorrow and get it merged. |
Looks good, merging. Sorry this took so long. |
prevent event from being used to enter a newline into editor
this fixes brackets-userland/brackets-git#385
cc @TomMalbran @peterflynn