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.
This issue was reported manually by vv159170. It already has 1 duplicates Build: NetBeans IDE 7.0.1 Dev (Build 20110603-4e44b7e2d1d1) VM: Java HotSpot(TM) 64-Bit Server VM, 19.1-b02, Java(TM) SE Runtime Environment, 1.6.0_24-b07 OS: Linux User Comments: vv159170: invoking popup menu on folder in Favorites (folder is from remote FS) Maximum slowness yet reported was 21493 ms, average is 21493
Created attachment 108695 [details] nps snapshot
20 sec to wait for popup is way too long
Open project action from context menu is invoking very expensive method from UI thread Way to reproduce: - add remote FS to Favorites, - right click on folder
Two separate items in the snapshot: 1. OpenProjectList.LoadOpenProjects.resultChanged does some work synch, some asynch. It should likely do it all asynch. 2. OpenProjectFolderAction.ContextAction.<init> updates its label and enablement status based on project information. Surprisingly the snapshot does not show it blocking while loading the project - which would be plausible enough - but when getting the display name, which winds up loading the icon too, which is apparently nontrivial in a make project. Not obvious what the right fix is; it is probably necessary to immediately decide whether the project exists (so the menu item can be shown or not - unacceptable to remove a context menu item a moment after the menu appears), but setting the label could probably be done asynch.
For long validating actions we use the following approach: - show action in disabled state immediately and with text "ActionName (Validating...)" - Validation itself is run on bg thread - When finished => enable state is changed and text is updated as well It solves the problem for users who are not interested in action itself, but interested in other actions from popup menu
(In reply to comment #5) > For long validating actions we use the following approach Right, but not suitable for use with DynamicMenuContent.HIDE_WHEN_DISABLED.
(In reply to comment #4) > setting the label could probably be done asynch. Requires some changes in o.o.a.Actions, which is not expecting that. Even with that fixed, it does not really work well; if the label is changed to something longer than the usual popup width, at least in GTK L&F on JDK 6 the menu item is simply truncated - i.e. the JPopupMenu does not expand to hold it - which looks terrible. The only fix I can think of is to simply not adjust the menu item label to match the project display name at all.
core-main #a0eaffd59b2d
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/94c7c19e4edb User: Jesse Glick <jglick@netbeans.org> Log: Permit actions bound to menu items to update visible properties (e.g. label) asynchronously. (Mentioned in bug #199137 comment #7 though not used in that case as Swing does not seem to handle this well.) Non-menu bridges could already do so; for menus, the hierarchy listener was disabled, but the regular listener was never added. Also making the regular listener weak, in case a singleton action somehow acquires many presenters (possible though unlikely).
Have you been able to verify the fix? Do you need it backported to 7.0.1?
I don't know if it works better, because I still get 10-15 sec delay which is now associates with http://netbeans.org/bugzilla/show_bug.cgi?id=197004
Then I would probably ask for a waiver: the fix is probably safe, but is not known to be effective. Anyway I suppose that ironing out all the kinks in the remote filesystem support is going to take some time and is not something we can expect in 7.0.1.