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.
Development build #200604210200 of NetBeans 5.5 Windows XP, JDK 1.5.0_05 build #05 Description: ============ Links in javadoc window are almost impossible to use. If user clicks any link, IDE starts to look up all hosts in AWT thread which locks IDE for more than half a minute. User can't do anything with IDE. I am attaching the thread dump. Steps to reproduce: =================== 1. Create new web application project and HTML file inside. 2. Set cursor at position 3:4 i.e. <ht|ml> and press CTRL+Space. 3. Code completion shows up with javadoc window. 4. Click any link in the help window e.g. "lang". 5. IDE freezes for more than half a minute.
Created attachment 29968 [details] Thread dump taken while IDE was looking for hosts.
Probably something what should be modified into more general problem and escalated against JDK. If we had local copy of requested data we could try to modify link targets to reduce the probability of this problem.
I don't think this code is in HTML module, is it? Javadoc window is owned by the editor, reassigning.
This particular example seems to be working fine now, but the docs were loaded from a local zip file, so I don't know what the performance would be when accessing docs over a network. Could you please describe how to set up remote access to docs shown in completion? I tried Java Platform Manager and Library Manager, but they both require local folder or a zip file. Thanks.
I currently have a wrongly configured proxy so I see in my log: INFO [org.netbeans.core.NbProxySelector]: connectionFailed(http://www.w3.org/StyleSheets/TR/W3C-PR, webcache.uk.sun.com:8080) java.net.UnknownHostException: webcache.uk.sun.com It seems that we process html40.zip entries to assemble documentation window and the resource that we create still references www.w3.org site. If user has problems with network connectivity it is possible that it will behave like Jirka described. IMO we should generate documentation that will only access local resources. Assigning to HTML (html/editor/lib I guess). Hope we can add a test that will register handler for HTTP URL connections and checks if it is needed when we query for documentation.
Re Vita's question about access to remote documentation: what if you generate JavaDoc that references other libs/platform through http: (like we do for NetBeans API, see that there are links to http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Object.html)? Then we probably can see HTTP access in EDT when clicking to JavaDoc window too.
Simple way how to check that there is a network activity is to run 'tcpdump -p -i eth1 tcp port 8080' (or port 80, in my case communication goes through proxy with port 8080).
We have documentation mostly free of external links. There is a few external links, but not many and moreover it is almost impossible to use them locally. The described usecase link from HTML tag -LINK element *IS* referenced relatively, see following code from struct/global.html used for the help content: <h2><a name="h-7.3">7.3</a> The <a name="edef-HTML"><samp class="edef"> HTML</samp></a> element</h2> <div class="dtd-fragment"> <pre class="dtd-fragment"> <!ENTITY % html.content "HEAD, BODY"> <!ELEMENT <a href="global.html#edef-HTML" class="noxref"><samp class= "einst">HTML</samp></a> O O (<a href= "../sgml/dtd.html#html.content">%html.content;</a>) -- document root element --> <!ATTLIST HTML <a href= "../sgml/dtd.html#i18n">%i18n;</a> -- <a href= "dirlang.html#adef-lang">lang</a>, <a href="dirlang.html#adef-dir">dir</a> -- > </pre> </div> It looks like there is something causing these links not to be resolved relatively, but instead of them an externall link is created. Isn't this handled by the documentation window handling code?
Cannot reproduce...
Not easy to reproduce, cornercase IMHO => LATER.
NetBeans.org Migration: changing resolution from LATER to WONTFIX
Well, okay. It's much faster now (~1-2 seconds) although I still think it downloads the documentation from w3.org.