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.
Steps to reproduce 1. Create a maven web project (set the runtime Server to Tomcat, any java ee version) 2. After the project is created, in the Projects window, right click on the newly created project. Select Properties from the contextual menu 3. In the Project properties window clic the Run category. Expected result: as for the other categories the node is selected and runtime relevant information is displayed. Actual result: The IDE is stuck. No way to close the window. It can only be minus nine killed. No exceptions in /Users/joe/Library/Application Support/NetBeans/7.4.../var/log/messages.log
Could you please attach thread-dump http://wiki.netbeans.org/GenerateThreadDump, attach it here and reopen ? Thanks in advance.
Created attachment 138459 [details] requested thread dump
requested thread dump has been attached
MacBrowserImpl is blocked because it's waiting for process called "defaults read com.apple.LaunchServices" - I have no idea what it does. Anyway I don't see anything wrong on Maven side. The only thing Maven is using is web.browser.api.BrowserUISupport.getDefaultBrowserChoice(true) and that does seem to be correct. Reassigning back to extbrowser (or maybe the evaluation should be done in web.browser.api.. can't say for sure). Please if I'm using the API in a wrong way, feel free to reassign back. Thanks in advance BTW: I wasn't able to reproduce neither on Ubuntu nor on Mac OS
I reassigned to Maven because it is calling the getDefaultApps methods from 2 threads at the same time: from org.netbeans.modules.web.clientproject.browser.ActiveBrowserAction and from AWT-EventQueue-0. Is that correct? The "defaults read com.apple.LaunchServices" process is just a way to find out the default browser on Mac - that's the correct and tested way. But why is it called from 2 threads? I must say I can't reproduce this either.
(In reply to Petr Jiricka from comment #5) > it is calling the getDefaultApps methods from > 2 threads at the same time: from > org.netbeans.modules.web.clientproject.browser.ActiveBrowserAction and from > AWT-EventQueue-0. Is that correct? IMHO, the AWT call is definitely correct. User is trying to go to the Run properties, but probably don't have set any browser so the code is trying to get the default one (--> at the code ends within MacBrowserImpl.getDefaultApps(..)). Don't know when the ActiveBrowserAction.updateButton(..) method is called. Tome, Davide? Maybe we would be able to reproduce it with such knowledge.
Tomas could you review my fix please? It fixes the issue we talked about offline a while ago; I also did a small change in NbDefaultUnixBrowserImpl. Thx. web-main#13d9c4914376 I fixed synchronization and default OS browser detection is now always run only once per IDE - if user changes OS browser they will have to restart the IDE. I also renamed getDefaultPrivateBrowserFamilyId as detectPrivateBrowserFamilyId and method is always guaranteed to be called in background thread - upon opening browser it may have different icon and type until beackground thread finished the detection and changed property. WebBrowser listens on the browser event change and updates automatically the "IDE's default browser" browser.
Re-adding default constructor otherwise "Add" browser button in Options fails. web-main#8993cdd7e37f
Well, I had a look at the fix but unfortunately my knowledge of extbrowser is quite poor... But your description of the patch makes perfect sense to me (I wanted to do something similar some time ago but was not able to do it) Just one minor note: private transient AtomicBoolean detected = new AtomicBoolean(false); should IMHO be: private final AtomicBoolean detected = new AtomicBoolean(false); Thanks.
(In reply to Tomas Mysik from comment #9) > Just one minor note: > private transient AtomicBoolean detected = new AtomicBoolean(false); > should IMHO be: > private final AtomicBoolean detected = new AtomicBoolean(false); Could be final but must stay transient. That's what hit me unexpectedly while fixing this issue: if user edits browser configuration in IDE options the changes are saved using Java Serialization and NetBeans XMLSettings support. And "detected" should not be serialized. Java Serialization sucks man and I thought it is gone from NetBeans by now but obviously not.
Aha, I see now...
verified in Build 201308141142. Not reproducible. Thank you for the fix.