Bug 544529 - [content assist] Asynchronous content assist completion doesn't keep selected proposal in CompletionProposalPopup
Summary: [content assist] Asynchronous content assist completion doesn't keep selected...
Status: ASSIGNED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Text (show other bugs)
Version: 4.11   Edit
Hardware: All All
: P3 normal with 1 vote (vote)
Target Milestone: ---   Edit
Assignee: Platform-Text-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: bugday, helpwanted
Depends on:
Blocks: 531061
  Show dependency tree
 
Reported: 2019-02-18 05:11 EST by Bence Sipka CLA
Modified: 2019-09-17 08:56 EDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bence Sipka CLA 2019-02-18 05:11:27 EST
When asynchronous content assistant is used to compute the proposals then if multiple IContentAssistProcessors are used, then the selected proposal is reset when the proposal computation is done on the second processor.

In the following scenario, multiple IContentAssistantProcessors are used. The first one computes some proposals fast/instantly, and the second one takes more time to compute (like more than 1 sec.). When the content assistant is invoked, then the proposals from the quicker processor is displayed with an another proposal that says "Computing proposals (50%)".

The user proceeds to select some proposal from the first processor while the second one is computing. Then the second processor finishes computation and the proposal popup resets. 

After the popup reset the previously selected proposal by the user will reset as well, to the proposal at index 0. This is not desirable, as the user would have to navigate to the previously chosen proposal again.

This is due to the fact that at the end ofCompletionProposalPopup.setProposals method the code will select the proposal explicitly at the index 0. The method should instead use the stored last selected proposal ( fLastProposal ), and calculate the index of the proposal in the new proposal list.

The following method call should be replaced:

https://git.eclipse.org/c/platform/eclipse.platform.text.git/tree/org.eclipse.jface.text/src/org/eclipse/jface/text/contentassist/CompletionProposalPopup.java
CompletionProposalPopup.java:1207

    selectProposal(0, false);

replaced for

    selectProposal(Math.max(0, proposals.indexOf(fLastProposal)), false);

The Math.max() call necessary to avoid errors when the last proposals is not found in the new list, therefore indexOf could return -1. We fall back to the first element in this case.

The variable proposals cannot be null or empty at that point of the call, as it is checked earlier in the method. (:1185)

Additionally, instead of indexOf, identity comparison could be used for calculating the new index, but that is not really necessary.
Comment 1 Mickael Istria CLA 2019-02-27 11:08:03 EST
It seems like you got a full understanding of the issue, its cause and possible remediation. Are you willing to submit a patch?
Comment 2 Mickael Istria CLA 2019-03-06 12:20:04 EST
(In reply to Mickael Istria from comment #1)
> It seems like you got a full understanding of the issue, its cause and
> possible remediation. Are you willing to submit a patch?

@Bence: ^ ping ;)
Comment 3 Mickael Istria CLA 2019-05-31 11:59:46 EDT
Since the issue is well analyzed and described, it can be a good issue for a new contribution.