Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 496208

Summary:	codeEdit: Quick fix does not appear if editor does not get focus.
Product:	[ECD] Orion	Reporter:	libing wang <libingw>
Component:	Editor	Assignee:	Curtis Windatt <curtis.windatt.public>
Status:	RESOLVED FIXED	QA Contact:
Severity:	major
Priority:	P3	CC:	curtis.windatt.public, Silenio_Quarti
Version:	12.0
Target Milestone:	13.0
Hardware:	PC
OS:	Windows 7
Whiteboard:

Description libing wang

2016-06-15 14:15:44 EDT

In demo http://libingw.github.io/OrionCodeEditTern/, click on the second editor, .tern-project, and then hover on "import" in the first editor.

Quick fix does not appear unless you click on the first editor again.

Orion does not have this issue. I opened split editors and verified.

Comment 1 libing wang

2016-06-15 14:26:11 EDT

Actually I could reproduce it in Orion now:
1. Open two editors in split mode.
2. Put something in the left hand editor, with annotations and potentially quick fix will show up.
3. On the right hand editor, leave it empty, or, put clean contents without annotations.
4. focus on the right hand editor.
5. Now hover something on the left hand editor.

You will see no quick fixes.

Comment 2 libing wang

2016-06-15 14:34:39 EDT

Reminder that yourSelfHost.orion.eclipse.org:9000/embeddedEditor/demo/demoCodeEditTern.html will verify the fix as well.

Comment 3 Curtis Windatt

2016-06-15 16:53:38 EDT

This happens when there is more than one editor (code edit widget with multiple windows or split editor).  When the commands are being rendered they need information about the editor (specifically for visibleWhen()).  The editor being asked for this information is whichever editor has focus.  Hovering on a tooltip does not change the active editor so visibleWhen() fails and no quickfix commands are rendered.

I made an attempt at changing the editor because the command handler points at the editor we want.  However, this does not fix the problem because actual visibleWhen validation is done against the items.  The items object has a slew of information about the editor with focus (contentType, location, etc.).

We could instead look at having the editor gain focus whenever a tooltip is hovered.

Comment 4 libing wang

2016-06-16 10:30:43 EDT

(In reply to Curtis Windatt from comment #3)
> We could instead look at having the editor gain focus whenever a tooltip is
> hovered.
Just my two cents:
As an end user, I would not like the editor get focus until I click the mouse. Maybe we should invent a new category of command, like, "show me event the editor is not current". Just a thought...

Comment 5 libing wang

2016-06-16 10:38:17 EDT

Hmm, thought it over, maybe activating the editor when tooltip shows up is the only and easy way to do it now.

Comment 6 Curtis Windatt

2016-10-06 17:16:05 EDT

http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=c3571c4918c9f31a797b6095de81de20e265a1c2
Fixed in master

Fix is in two parts
1) When rendering commands we need to validate them against the annotation's editor.  Editor commands replaced the items (which had the correct info) with the file metadata from the wrong editor. Fix is to not do this replacement if validating a quick fix command.

2) When performing the command, the input manager used is correct, but the editor is not.  Tried getting the editor from the input manager, but this returns the active editor (this might be a bug, or a feature depending on the implementation of split editors).  Fix is to use the editor stored in the creatorID field of the annotation.