Community
Participate
Working Groups
- Create an empty test.js file in a project that does not have a .tern-project file. - Type the following line of code into the file (including carriage return): import "somelib"; - The tooling marks the word 'import' with an error (good). - Type Up Arrow to put the caret at the beginning of the word 'import'. - Type F2 - the tooltip opens and the quickfix button has focus (good). - Type Enter or Space - a .tern-project file is created (good). - The tooltip does not go away (bad). You can see this with the mouse by not moving it after clicking on the button, but it is more likely to happen for a keyboard-only user. Workaround is to wiggle the mouse, or type arrow keys or text, to make the tooltip hide. Note that typing Escape (which would normally hide the tooltip after typing F2) does nothing because the tooltip doesn't have focus any more. I think the correct fix is to close the tooltip after a quickfix is applied.
This problem shows up on the codeEdit demo page, so would be nice to have it fixed. http://libingw.github.io/OrionCodeEditTern/
It's worth noting this only happens for quick fixes that don't modify the editor contents.
Yep - agreed. It's a special case. Unfortunately it's front-row-center in the codeEdit tooling demo. :)
I'm aware that in the multi-file code edit demo it's very obvious. If needed we can modify that quick fix to touch the editor. I'm looking at whether there is a fix we can do for all quick fixes.
(In reply to Curtis Windatt from comment #4) > I'm aware that in the multi-file code edit demo it's very obvious. If > needed we can modify that quick fix to touch the editor. I'm looking at > whether there is a fix we can do for all quick fixes. I don't think a good solution is to have the quickfixes work around the problem. A better fix would be to have the fix button fire an event / use a callback so the popup knows to be torn down - just like we do for the proposals popup.
(In reply to Michael Rennie from comment #5) > I don't think a good solution is to have the quickfixes work around the > problem. A better fix would be to have the fix button fire an event / use a > callback so the popup knows to be torn down - just like we do for the > proposals popup. Agreed. Better to separate the tooling from the UI details.
http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=78f112068abc894be1946e47cbaf0f31773371cb Fixed in master We now pass a post quickfix callback in the user data we give to the commands. When a quickfix button is activated, the callback will be called after command invocation. Currently the callback simply calls hide(), but if needed we could use this to perform additional operations (like relint the file).
*** Bug 500696 has been marked as a duplicate of this bug. ***
