This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 66803 - Bogus dependency matches in add dependency dialog
Summary: Bogus dependency matches in add dependency dialog
Status: VERIFIED FIXED
Alias: None
Product: apisupport
Classification: Unclassified
Component: Project (show other bugs)
Version: 5.x
Hardware: All All
: P3 blocker (vote)
Assignee: Martin Krauskopf
URL:
Keywords: RANDOM, THREAD
Depends on:
Blocks:
 
Reported: 2005-10-14 13:16 UTC by _ tboudreau
Modified: 2005-11-22 15:21 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Screen shot (15.49 KB, image/png)
2005-10-14 13:16 UTC, _ tboudreau
Details
bad_linux (27.02 KB, image/png)
2005-10-24 20:20 UTC, Martin Krauskopf
Details
good_linux (11.02 KB, image/png)
2005-10-24 20:20 UTC, Martin Krauskopf
Details

Note You need to log in before you can comment on or make changes to this bug.
Description _ tboudreau 2005-10-14 13:16:06 UTC
The add dependency dialog sometimes comes up with completely wrong matches for
classnames typed in the filter field.  Oddly, sometimes pressing backspace will
fix it - the dialog seems to sort of squirm as you type, and sometimes comes up
with more results when you've typed additional characters and such.  

I'm guessing it's some race condition and more than one thread is off looking
for matches, or one thread ends up returning matches for what was there before
the user typed more characters, or something such.

See attached screen shot.
Comment 1 _ tboudreau 2005-10-14 13:16:34 UTC
Created attachment 25950 [details]
Screen shot
Comment 2 Jesse Glick 2005-10-14 19:42:46 UTC
Working fine for me. Have never observed such a problem.
Comment 3 _ tboudreau 2005-10-24 19:49:29 UTC
Still seeing this in 10/21 build.  Simply start with an existing userdir, create
a new project (say, in contrib), open properties for it, click Libraries, Add.

Now just type AbstractFileObject quickly.  When you've finished typing, the
dialog has what I can best describe as a sneezing fit, flashing back and forth
several times between FileSystem API an a big list of non-matches;  finally it
settles down to the big list of non-matches.

It may have to do with typing speed or something.  What really looks like is
happening is that there are several background tasks competing to match what
I've typed, and a task that matches something like "Abstract" finishes *after*
the one that matched the complete string, and so it wins and gets its results
displayed.  Subsequent invocations against AbstractFileObject will work fine -
seems to be specific to the first invocation.  The flashing behavior is quite
bizarre.
Comment 4 _ tboudreau 2005-10-24 19:51:27 UTC
Just a side thought - if you've never seen it, Jesse, could it possibly be
windows-specific (i.e. no thread priorities on linux would change the behavior,
I'd imagine, and it seems to really be a timing issue).
Comment 5 Martin Krauskopf 2005-10-24 20:19:37 UTC
I think that I also saw this problem few times few weeks ago - on Linux (I was
on vacation - so not sure about current state). Also IIRC Petr Zajac reported
similar problem. Probably some threading issue.....
....ups, just reproduced. See screenshots. First time 'ads' matching all
entries, second time only one (which is correct).
Comment 6 Martin Krauskopf 2005-10-24 20:20:34 UTC
Created attachment 26294 [details]
bad_linux
Comment 7 Martin Krauskopf 2005-10-24 20:20:55 UTC
Created attachment 26295 [details]
good_linux
Comment 8 Jesse Glick 2005-10-24 22:04:31 UTC
All right, will look at it.
Comment 9 Martin Krauskopf 2005-11-03 13:38:22 UTC
Having a pseudo-randomly failing test. Should be easy to fix now. I'll try to
fix it.
Comment 10 Martin Krauskopf 2005-11-03 14:13:02 UTC
Problem is that as you typed into the filter value, it becomes possible that few
threads computing filter are run. So e.g. if you type in "org.op" it would be
possible that "org.op" filter thread finishes faster than "org" thread. So then
the "org.op" result model was replaced by "org" result model.
Comment 11 Martin Krauskopf 2005-11-03 14:40:17 UTC
Fixed.

Checking in ui/customizer/AddModulePanelTest.java; 1.1
Checking in test/unit/ui/customizer/SingleModulePropertiesTest.java; 1.25 -> 1.26;
Checking in ui/customizer/AddModulePanel.form; 1.8 -> 1.9;
Checking in ui/customizer/AddModulePanel.java; 1.26 -> 1.27;
Comment 12 Tomas Danek 2005-11-22 15:21:01 UTC
not reproducible in current trunk, consider as verified.