Community
Participate
Working Groups
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.0.14) Gecko/2009082707 Firefox/3.0.14 Build Identifier: 20090920-1017 Use case: present the user with a field assist to input some data. The fetch of the proposals from the database is rather expensive (~0.5 sec) so we set a moderate autoActivationDelay of 500 msec. When typing quickly, the popup opens 500 msec after the FIRST key type, not after the LAST one. The proposals are then calculated for every additional key (as the proposal popup now is open), which slows user input unnecessarily down. My analysis is: The ContentProposalAdapter.autoActivate() method starts off a new Thread that sleeps for the specified autoActivationDelay, checks for intermittent key strokes and then opens the popup. It does this for any key stroke so there may be more than one such thread running/sleeping at a time. The problem is with the flag receivedKeyDown, that is set to false by the event handling thread after autoActivationDelay and to true by the key handler. If the delay is long enough that the user manages to fire more than one additional key events during the sleep phase of such a thread, the first key's open popup thread will clear the receivedKeyDown flag and hence the second key's open popup thread will open the popup, regardless of the events that might have followed. Reproducible: Always
My suggested fix would be to have the autoPopup() method make sure that any sleeping thread will not open the pop up before spawning a new popup thread. I'll attach the patch shortly.
Created attachment 151349 [details] Patch (perhaps more a hack? not sure if its good) Patch against org.eclipse.jface/src/org/eclipse/jface/fieldassist/ContentProposalAdapter.java # 1.71 I'm not sure if this is a bullet-proof way to fix the issue.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
