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.
[pilsen](010803),[nb_dev](20010810),[jdk1.3.1](rc1) I have set as default browser Netscape, If I select one of links in Bookmarks Netscape is open and page is loaded. If I select link in Help nothing happen, Netscape is closed and I hear only beep.
Which link in the Help menu? A URL link? Maybe something to do with *.url support, maybe with extbrowser, I don't know...
Opps, it's not about Help menu but Help window.
This is not problem of external browser. Help is trying to use some internal HTML browser when user clicks on url with HTTP protocol. It works fine if you have icebrowser installed and set proxy (even if prefered browser is set to external one).
Since icebrowser isn't in the distribution any more, is there anything we can do about this?
Sorry I forgot to add these comments earlier. Currently, URLs presented in the help are intentionally not hot-linked since they would be opened up in JavaHelp, not your specified web browser, and would be rendered horribly. I don't think it matters whether or not icebrowser is installed. Another possible point of confusion: in much older versions of NetBeans, we used Icebrowser to display JavaHelp for performance reasons. However, we switched back to the standard Swing JEditorPane implementation (once its performance improved) to take care of the navigation features it provides. Now JavaHelp and Icebrowser have nothing to do with each other in the IDE. Now the question is whether it is possible (and desirable) to be able to have HTTP URLs clicked on in the IDE's JavaHelp window to open up in the web browser designated by the user.
Closing as WONTFIX. Links in the core help are intentionally not hot-linked. They could be hot-linked and displayed in the JavaHelp browser, but they would render poorly and disrupt navigation in the help system. They could also be made, in theory, to be viewed in the web browser of choice, but there are certain obstacles here (like knowing which web browser to call and the assumption that the user has correctly configured proxy settings) that are probably not worth trying to climb given the lack of outside links in the docs. If anybody feels strongly about this issue, perhaps it can be revisited as an RFE.
Resolved for 3.3.x or earlier, no new info since then -> closing.
Resolved for 3.4.x or earlier, no new info since then -> closing.