Currently we have code in a lot of places that manually returns focus to the editor after various operations. This causes bugs whenever one of these operations is invoked while the focus is not in the main editor. For example:
Open an HTML file, then hit Ctrl+E to bring up an inline editor. Then hit Ctrl+S. Focus jumps back to the outer editor.
Same, but instead of Ctrl+S switch to a different app and then return to Brackets. Same result.
Same, but instead of Ctrl+S hit Ctrl+O and then cancel the Open dialog. Same result.
Same, but (with unsaved changes in the HTML file) hit Ctrl+W and then hit Cancel on the confirmation dialog. Focus returns to the outer editor from the dialog, not the inline editor.
File > New, and begin typing a new filename. Then hit Ctrl+S. The new file is immediately created using whatever text you had entered so far, and focus jumps back to the main editor.
File > New, and begin typing a new filename. Then hit Ctrl+O and Cancel the Open dialog. Same result.
We might instead want to have a central focus manager that makes sure focus doesn't arbitrarily go away from the editor. Then all our individual operations won't be trying to "correct" the focus location all the time.
Another alternative: many web browsers have (nonstandard) APIs for marking sections of the UI as non-focusable, or at least as not grabbing focus upon mousedown. If we use those APIs well enough, we may not need any sort of focus manager at all.
Issue by jlondon Tuesday Feb 21, 2012 at 19:50 GMT Originally opened as https://github.com/adobe/brackets/issues/301
Currently we have code in a lot of places that manually returns focus to the editor after various operations. This causes bugs whenever one of these operations is invoked while the focus is not in the main editor. For example:
We might instead want to have a central focus manager that makes sure focus doesn't arbitrarily go away from the editor. Then all our individual operations won't be trying to "correct" the focus location all the time.
Another alternative: many web browsers have (nonstandard) APIs for marking sections of the UI as non-focusable, or at least as not grabbing focus upon mousedown. If we use those APIs well enough, we may not need any sort of focus manager at all.