Because this is the user behavior when writing a search box.
Even without user-testing this, you can rest on well-known patterns that you use everyday: You write something on Chrome's address bar and press 'Enter' to go for it. You write on Google Search Box and you press 'Enter' to get results (also with live-search). Same here, on Github.
Even when the live-search feature is enable, the User could not be aware of this feature because of keypress timeouts, delayed server responses or even for looking at the keyboard while writing. So once he is done writing will press 'Enter' to send the request.

Another example, that might be more towards this use case: chrome://settings/. In chrome://settings, it does auto-search, but the enter button doesn't close the tab. It might be as simple as (and I am doing a bit of hand waving here) adding a keyUp handler that filters out the enter button's default behavior.
Please do this, I keep hitting enter
This may be related to some Adobe's guidelines since I have seen this behavior present on other Adobe's apps such as Photoshop or Illustrator.
But as I said before I think this is a misconception and should be reverted.
This bothers me so much. It breaks simple UI laws, why should a window close on ENTER, since we already have ESC for closing it?
This should be an easy thing to fix, PRs are welcome.
Duplicate of #6904, but I'm going to leave both open.
@zaggino can I take it? Looks like a good starter bug 馃槃
Sure @sahildua2305 , go ahead.
Thanks @zaggino!
I figured out that it's here that ESCAPE key event is defined. Since, the same action on ENTER key is by default, we should disable the default event triggering from ENTER key?
Am I thinking in the right direction?
Possibly, ideally try debugging what event/code makes it close after Enter and then it'll be clearer where you need to change the code.
Is there an efficient way to debug this application? (Like putting up some debug messages or things like that?)
Debug > Show developer tools menu will open classic Chrome developer tools where you'll see all the Brackets source. It's easy to debug there, you can put breakpoints whereever you want and go through code step-by-step.
You need to be running Brackets from source: https://github.com/adobe/brackets/wiki/How-to-Hack-on-Brackets
Hi,
I made a change in this line, and now when you type inside the search box it doesn't close. However, the main extension manager dialog box is still closing.
Am I on the right track?
Yesterday I took a look and come to similar conclusion: replacing $primaryBtn.click(); with return true seemed to fix the issue (at least for Theme dialog).
I don't know if it is right maybe @zaggino know/remember why is there that line.
Keep in mind there are already a couple of people looking at this issue.
See https://github.com/adobe/brackets/commit/046aa948f4110d540d554e7085bf1040510e3345
It's like this, you hit enter:
If you're focused on a button, click that button
Else click primary button (in this issue, closes the dialog which is what we don't want)
Solution is simple, you need to add one condition there:
If you're focused on a input e.target.tagName === "INPUT", don't do anything
Thanks for the pointer @zaggino
I have created a PR to fix the issue. Please review it :)
@petetnt I'd love to contribute more. Let me know if you know of a bug that you think will be good to solve to begin with. 馃槃
Thanks for taking care of this. 馃憡
Most helpful comment
Debug > Show developer toolsmenu will open classic Chrome developer tools where you'll see all the Brackets source. It's easy to debug there, you can put breakpoints whereever you want and go through code step-by-step.You need to be running Brackets from source: https://github.com/adobe/brackets/wiki/How-to-Hack-on-Brackets