Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 337313 - Content Proposal only activated by the second key stroke
Summary: Content Proposal only activated by the second key stroke
Status: RESOLVED FIXED
Alias: None
Product: RAP
Classification: RT
Component: JFace (show other bugs)
Version: 1.4   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 1.5 M5   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 330461
  Show dependency tree
 
Reported: 2011-02-16 09:15 EST by Moritz Post CLA
Modified: 2012-01-18 06:24 EST (History)
1 user (show)

See Also:

Attachments
Entry point to reproduce it (4.14 KB, text/plain)
2011-02-18 08:50 EST, Ivan Furnadjiev CLA 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Moritz Post CLA 2011-02-16 09:15:44 EST 
When using the content proposal API to create content assist, the assist is only activated on the second key stroke. In RCP it reacts to the first char. That might be related to the fieldassist API.
Comment 1 Ivan Furnadjiev CLA 2011-02-18 08:50:19 EST 
Created attachment 189272 [details]
Entry point to reproduce it
Comment 2 Ivan Furnadjiev CLA 2011-02-18 09:28:01 EST 
The actual problem is the wrong (different from RCP) value of "position" parameter of IContentProposalProvider#getProposals method. When you type the first character, the "position" parameter is 1 in RCP, but 0 in RAP. The attached snippet returns empty array with proposals if "position" is 0. ContentProposalAdapter is heavy use Key Events. The proposals shell is auto activated on KeyDown event if autoActivationCharacters are set or on Modify Event if they are not set. Because key events are fired before setting the text caret position we get wrong (previous) caret position. For now, the workaround is to *NOT* set the autoActivationCharacters.
Comment 3 Tim Buschtoens CLA 2012-01-18 06:11:20 EST 
Fixed in CVS HEAD.

The more general underlying problem was that key events are send before they are processed by the client, so widgets influenced by the key event dont have a chance to update. Fixed by sending the request asynchronously (i.e. with a timeout of 0 ms). My reasearch showed that even if the timer is started on keydown, it wont trigger until after the following keypress event.