[CLOSED] Fix for #6904 - Pressing [Enter] in Extension Manager Search box closes Extension Manager

[core-ai-bot]

Issue by ingorichter
Thursday Mar 27, 2014 at 21:13 GMT
Originally opened as adobe/brackets#7337

---

This will prevent that the Extension Manager Dialog will be closed when the Enter key is hit inside the search field.

---

ingorichter included the following code: https://github.com/adobe/brackets/pull/7337/commits

[core-ai-bot]

Comment by ingorichter
Tuesday Apr 22, 2014 at 23:11 GMT

---

Okay, what is the conclusion? We want a different fix for this issue?

[core-ai-bot]

Comment by TomMalbran
Tuesday Apr 22, 2014 at 23:53 GMT

---

I guess that the easiest solution would be to have a special class for the search inputs and then change https://github.com/adobe/brackets/blob/master/src/widgets/Dialogs.js#L152 so that it takes into account the search inputs.

[core-ai-bot]

Comment by peterflynn
Thursday Apr 24, 2014 at 01:42 GMT

---

@TomMalbran I like that idea! Nice and simple.

[core-ai-bot]

Comment by TomMalbran
Friday Apr 25, 2014 at 05:38 GMT

---

@peterflynn What do you think about using an input type search and removing the browser's default styles?

[core-ai-bot]

Comment by ingorichter
Friday Apr 25, 2014 at 06:30 GMT

---

I think it's weird to handle a very specific case in the general purpose dialog class. Do we have more search input fields where we want this behavior?

[core-ai-bot]

Comment by TomMalbran
Friday Apr 25, 2014 at 06:33 GMT

---

Not yet, but we might need it later for the Preferences UI, and maybe for other similar UI we make or that extensions authors make that would use a search input. To me is not a very specific case, but a common one, and the dialog is already handling several cases.

[core-ai-bot]

Comment by ingorichter
Monday May 05, 2014 at 19:48 GMT

---

I can add this to the Dialog class, but I'm not convinced that this is the right solution nor do these other special case handlings belong there. This might be the easiest way to fix it. I think this should somehow be configurable by the creator of the dialog. Otherwise somebody doesn’t like a specific behavior that we provide with the general purpose Dialog implementation.

[core-ai-bot]

Comment by TomMalbran
Monday May 05, 2014 at 20:05 GMT

---

In that case we could use a more generic class with a name that would imply that enter won't be executed after being pressed.

Another possibility could be to pass a keydown handler function that is executed before _keydownHook and _keydownHook is only executed if the given handler returns a falsy result. This function could be a new parameter when creating the dialog, or since it will only used a few times, we can add a new method to the Dialog class that is returned when creating the dialogs, that will allow to add 1 or more keydown handlers.

[core-ai-bot]

Comment by njx
Tuesday Jul 08, 2014 at 19:08 GMT

---

Unassigning myself. I haven't fully digested the comments above, but it looks like this PR is not ready to go as-is since there's some desire to follow an alternate solution.@ingorichter Do you want to consider closing this and coming up with a different fix along the lines that@TomMalbran is proposing? Or@TomMalbran, maybe you'd like to implement a new fix?

[core-ai-bot]

Comment by busykai
Saturday Jan 03, 2015 at 00:42 GMT

---

FWIW, we also have File -> Project Settings and View -> Themes. In the Project Settings case, closing on enter seems natural -- it only has one field. In case of Themes (which wasn't there at the time of the discussion above), it does not feel right to close the dialog when you focus on, for example, Font Size and hit enter. So it sounds like a special "marker" class which would make Dialog to ignore Enter would be a nice solution (if I understand it right, it is what@TomMalbran suggests). Extensions with complex configuration could benefit from it, e.g. Brackets git.

Another question is what's the right behavior should be: should it just stay on the input field and do nothing, should it switch the focus to the default button, should it act as tab? Should there be different classes for different behaviors?..

[core-ai-bot]

Comment by rroshan1
Tuesday Mar 31, 2015 at 06:27 GMT

---

It would be good if we could reach some consensus on the fix for this issue. This issue is experienced by many and it has been open for quite long now.

[core-ai-bot]

Comment by ficristo
Saturday Oct 29, 2016 at 07:23 GMT

---

Superceded by #12839