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.
dev build 200609010000 If Glassfish is installed into "c:\program files\glassfish" then runtime -> servers -> glassfish -> open admin console will result in an exception getting thrown. I believe this has been fixed in 6.0 but has not been backported into 5.5
-> sunappserv
I could not reproduce. When you can, please attach the entire exception and reopen the bug. Also, code in 6.0 is older than 5.5. 5.5 is the live branch for Java EE development.
Created attachment 33628 [details] stack-trace
Please see attached stack-trace.
Not sure it is related to GlassFish, but more on the known browser from the IDE. See the message: Annotation: Could not access the URL through the external browser. Check the browser configuration. From the Tools menu, choose Options. Click 'Classic View' button, expand IDE Configuration/Server and External Tool Settings node, then expand Web Browsers and choose valid browser. " Can you tell which browser is configured there and how? Any chance to have more stack trace info (if any)?
I have "default browser" selected (which is FireFox for me). If you tell me how to get more stack-traces I'll give them to you :)
:-) Can you test this for me: install GF in a non space dir, register it: Do you see the same behaviour? Also, can you confirmed you are not using Windows Vista? We have several bugs around that on latest (yet to be released) OS.
Cannot reproduce. Can you test other ways to display the broswer from netbeans? For exalp,e in the welcome screen links or by running an app on tomcat?
You're right. View -> Web browser causes the failure regardless of Glassfish. This is 100% reproducible under Windows XP and FireFox ("C:\Program files\Mozilla Firefox"). Can you reproduce under a similar environment on your end? BTW: This would be a regression because it used to work in 5.0 and 6.0.
Please bump to P2, is you think this is blocking you. on my PC, it works with firefix in a dir with space
Bumped up to P2 as this occurs frequently and is a regression. What information do you need from my end to track down the underlying problem?
It would be helpfull if you could run the IDE with following parameter: -J-Dorg.netbeans.modules.extbrowser=-1 Either pass it from command line or add this to a netbeans.conf file. This will print extra debug information into messages.log file located in your user directory containg IDE specific data (Help|About| Detailshows where is Userdir). Then please attach the log file to the issue.
Created attachment 33769 [details] extra logging
I've attached the log. I don't understand why you've attached the keyword RANDOM to this issue as it is 100% reproducible on my end.
thanks for instant reply. By RANDOM I mean it is not always reproducible at any end and we don't know the exact conditions to reproduce it yet. As a matter of fact computers are fairly deterministic :-)
But... it isn't random :) Are you saying you can't reproduce this on your end under Windows/FireFox by running "View -> Web browser" from inside Netbeans?
Yes, I cannot reproduce it :-(
Okay, looks like it has to do with the proxy settings. If I change from "use system proxy" to "none" then suddenly the problem goes away. How do I expose what proxy settings Netbeans sees? PS: I verified that this issue occurs on a clean userdir on both JDK 1.5.0_07 and JDK 1.6.0 b97.
Yet another information can be obtained with -J-Dorg.openide.execution.NbProcessDescriptor=-1 Can you attach IDE log with output from this test?
It seems that -J-Dorg.openide.execution.NbProcessDescriptor=-1 doesn't produce any extra output. Is there another switch we can use?
My fault - I was looking into trunk sources. -J-DIDE-Exec=-1 in release55 and -J-Dorg.openide.execution.NbProcessDescriptor.level=500 in trunk (upcoming 6.0).
IDE-Exec=-1 doesn't seem to provide enough information. The only extra logging I get is: [IDE-Exec] Running: [C:\Program, http://www.netbeans.org/] I doubt this is enough for you to figure out why it is happening. Is there more logging I can enable? BTW: Turns out I was wrong, this bug has nothing to do with the proxy settings. The only thing that matters is whether Tools | Options | General | Web Browser is set to "FireFox" (which works) or "<Default System Browser>" which fails. The odd thing is that FireFox *is* my default browser :)
There might be some problem with reading from Win registry. I suggest to enhance SystemDefaultBrowser.defaultBrowserExecutable with some additional logging. Namely what is returned from native method and catch(NbBrowserException) handling where we can find what is wrong. Tomasz: will you create a patched build or should I add it directly to trunk so that Gili can test trunk build (with JDK1.5 because 1.6 uses different impl in trunk).
That won't work. As I originally mentioned, this problem does not occur in trunk but it does occur in 5.5. So either you add more logging into 5.5 or you try diffing the code against trunk and find out what is different in 5.5 which could be breaking it.
Created attachment 34234 [details] NB55 external browser module printing additional debug info
Please swap the attached file with 'ide7/modules/org-netbeans-modules-extbrowser.jar' on your local NB installation, so that we get additional debug info. Close your web browser before trying. Btw. does this problem also occur when your browser is already running? Can you reproduce it on NB 6.0 run on JVM 5.0?
The new log gives me: NbDdeBrowserImpl.getDefaultOpenCommand ()='C:\Program Files\Mozilla Firefox\firefox.exe -url "%1"' Looks like you should be surrounding the path up to firefox.exe with separate quotes as well as quoting %1.
This value is taken from Windows registry. We have tried on a number of Windows machines on our end and the returned string always included quotes. Obviously Windows is able to handle the path correctly with and without quotes and we should be able to do the same. We still want to know in what circumstances the quotes are not set in the registry in order to set appropriate priority for this issue. We will not aim to fix it in the 5.5 release unless it concerns a large group of users, because the fix would be risky at this stage. gtzabari, can you think of anything specific about your Firefox installation? What version is it and how did you switch between default browsers (if you did)? The workaround is to use registry editor to add quotes to the firefox path. Removing the RANDOM keyword as we finally know how to reproduce it.
Gili, please confirm whether the workaround works for you, after that let's downgrade to P3. Thanks.
You're going to have to tell me which registry entry to try changing because there are many of them that contain firefox.exe and the ones I've tried changing did not fix anything. Instead of defering fixing this issue, why don't you compare the current code to that of 5.0 or 6.0? Both have been working for me perfectly for many months so unless other users reported problems with them I would think it would be both easy and safe for you to merge their changes into 5.5.
What version of Firefox do you use now? I guess you will have the same problem in NB5.0 at this moment. NB6.0 can work well with your firefox if you run IDE on JDK6 but likely will fail in the same way on JDK5. We are not backporting this part of code from trunk into 5.5 because 5.5 is already in high reristance and there are some other problems (like pending bugs in JDK causing crash). The key we are looking for is found in two steps: HKEY_CLASSES_ROOT\.html contains name of app that is associated as default to .html files (something like FirefoxHTML). Than HKEY_CLASSES_ROOT\<name_of_this_app>\shell\command\open contains actual commad string that is split into executable and args.
I am using FireFox 1.5.0.7. You are right NB5.0 and NB6.0 both fail the same way using JDK 1.5 and NB6.0 works with JDK 1.6. NB6.0 "View Browser" does nothing, contrary to NB5.0 that actually brings up the browser. The only way to bring up the browser in NB6.0 is to run a Web project. Should I open up a separate bug report for this? For me, .html was associated with MyHTMLfile and MyHTMLfile/Shell/Open/Command had the FireFox path without spaces. Once I manually added the spaces the problem went away.
downgrading to P3 as this problem concerns a small group of users and a workaround exists. The problem will targeted in the 6.0 release.
It seems that this issue is obsolete now. Closing. Please reopen with up-to-date information if you experience it again.