Working fine for me. No recent changes that I know of. Thread dump does not show IDE doing anything, just sitting there with a dialog open waiting for you to do something.

Created attachment 95625 [details]
screen shot

- wait cursor
- scroll do not work
- only close dialog (by [x]) works

do not working for me

Don't know what to say. Something is broken on your machine, I guess. When you figure out what, let me know. Or if you can confirm that other people with recent builds on unrelated machines are having the same problem (but not with older builds), find the problematic change using bisection.

I also don't know what to say.
Today I fetch last changes from cnd-main, build Netbeans, and start netbeans.exe from nbbuild/netbeabs/bin on Windows XP.

>Log Session: Tuesday, March 23, 2010 8:58:12 PM MSK
>System Info:
  Product Version         = NetBeans IDE Dev (Build 100323-5ccc53b5e404) (#5ccc53b5e404)
  Operating System        = Windows XP version 5.1 running on x86
  Java; VM; Vendor        = 1.6.0_18; Java HotSpot(TM) Client VM 16.0-b13; Sun Microsystems Inc.
  Runtime                 = Java(TM) SE Runtime Environment 1.6.0_18-b07
  Java Home               = D:\Program Files\Java\jdk1.6.0_18\jre
  System Locale; Encoding = ru_RU (nb); Cp1251
  Home Directory          = C:\Documents and Settings\Alex
  Current Directory       = D:\Program Files\NetBeans 6.9\bin
  User Directory          = C:\Documents and Settings\Alex\.netbeans\dev

I am trying to open project from NB hg repository.
Netbeabs open dialog and:
- infinite waiting cursor
- scrolling does not works
- keyboard input is working

Are your sure that open dialog does not have a bug?
My advice:
- check why cursor is in "waiting" state.
It cannot be in "waiting" state infinite time.
It is a bug.

P2 because keyboard is working

Bug is reproduced on second a and next open project.

(In reply to comment #5)
> Are you sure that open dialog does not have a bug?

I can't be sure of anything until I know how to reproduce the problem. But I am unaware of any recent changes in clearly related areas like dirchooser or projectui.

Again, if you can confirm that builds from a few days ago are OK, then it would be possible to bisect history and find the problem, but the problem could just as well be in some environmental change rather than in the NB codebase.

> check why cursor is in "waiting" state.

If you can reproduce in a debugger, try to set a breakpoint on Component.setCursor and see what is going on.

Definitely break point on Component.setCursor() is a bad idea.
Any other breakpoint?
May be override setCursor() of IDE file chooser and set break point on it?

(In reply to comment #9)
> May be override setCursor() of IDE file chooser and set break point on it?

Maybe. Or look for usages of the wait cursor.

Wait cursor is set:
java.lang.Exception: set cursor type 3
        at org.netbeans.swing.dirchooser.DirectoryChooserUI.setCursor(DirectoryChooserUI.java:1659)
        at org.netbeans.swing.dirchooser.DirectoryChooserUI.access$1700(DirectoryChooserUI.java:108)
        at org.netbeans.swing.dirchooser.DirectoryChooserUI$UpdateWorker.run(DirectoryChooserUI.java:2495)
        at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1356)
        at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1894)

Is stack good enough reason to fix bug?
In stack you can see violation of thread model (use EDT method in non-EDT thread).
Please, do not close issue before fix (I can verify fix on my environment).

Eh, pardon my ignorance, but are there any steps to reproduce? Everything is working OK on my Ubuntu, so is this OS specific?
Yes I did some recent changes in order to fix some nasty bug and setCursor is called from non-EDT thread, but such a call was there for several years and didn't cause any troubles, so what's going on? Thanks.

IMHO it is a computer-performance specific.
Bug is easy (in 95%) reproduced on computer with 1 core with Windows XP.
My test case:
- invoke open project 
- point to NB hg sources
- click [x] to close dialog
- invoke open project again and see infinite wait cursor and unresponsive scroll bar and buttons (only keyboard input works)

Sorry, in test case you should select project first time to store folder.

Although I couldn't reproduce with production code, I was able to simulate thread slowness and confirm that there is an error - under certain circumstances, update of directory tree is skipped and there was missing call to restore regular cursor. Ugly time-thread related issue.

Anyway, fixed, Alexandr Simon please verify once my commit will find a way through build process into daily build, thank you.

fixed: 776729433cd0

Cannot verify due to exception (see Bug#182729).

It seems bug fixed.