This Bugzilla instance is deprecated, and most Eclipse projects now use GitHub or Eclipse GitLab. Please see the deprecation plan for details.
Bug 417947 - [KeyBindings] END/HOME keys are not behaving as expected when the content assist pop up is activated
Summary: [KeyBindings] END/HOME keys are not behaving as expected when the content ass...
Status: VERIFIED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 4.2.1   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: 4.4 M3   Edit
Assignee: Paul Elder CLA
QA Contact: Paul Elder CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-24 12:54 EDT by Martin Mathew CLA
Modified: 2013-10-02 04:51 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Mathew CLA 2013-09-24 12:54:45 EDT
Open a Java file and invoke content assist anywhere in the code.
Once the content assist pop up is activated, if user press END key, it is expected that the last option in the content assist pop up gets selected, similar behavior is expected for HOME key where it selects the first option available in the content assist pop up window.

This works in Eclipse 3.8.1, but from Eclipse 4.2 this seems broken.
Comment 1 Markus Keller CLA 2013-09-24 13:06:19 EDT
(In reply to Manju Mathew from comment #0)
> Once the content assist pop up is activated [..]
"is activated" here means "is shown". Once you give focus to the popup, then the END key works fine.


The END key should be handled in org.eclipse.jface.text.contentassist.CompletionProposalPopup#verifyKey(VerifyEvent), but we're not getting the keyDown event because the text editor has registered an END command that is not handled in this scenario.

org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher#executeCommand(ParameterizedCommand, Event) seems to think the command is handled but in the end doesn't find an active handler. org.eclipse.e4.core.commands.internal.HandlerServiceImpl#executeHandler(ParameterizedCommand, IEclipseContext) catches and stores the NotHandledException, but executeCommand doesn't seem to consult the stored exception and returns true, which means "eat the keyDown" (similar to to bug 358018).

A fix is to add the following in executeCommand, but I'm not sure if that's the correct fix:

if (staticContext.get(HandlerServiceImpl.HANDLER_EXCEPTION) != null) {
	commandHandled = false;
}
Comment 2 Paul Elder CLA 2013-09-25 14:13:17 EDT
Markus, thanks for the pointer. The entire try/catch around org.eclipse.e4.core.commands.internal.HandlerServiceImpl#executeHandler(ParameterizedCommand, IEclipseContext) is suspect. I've re-worked that and incorporated your suggestion. This is, I think, the desired behavior: the key dispatcher tries to find a handler for HOME/END, fails to do and so passes the key onto the active widget, which handles it.

Change submitted to Gerrit for review:

https://git.eclipse.org/r/16773
Comment 4 Dani Megert CLA 2013-10-02 04:51:41 EDT
Verified in N20131001-2000.