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.

Bug 269206 - Downloading JavaDoc locks up IDE
Summary: Downloading JavaDoc locks up IDE
Status: NEW
Alias: None
Product: ide
Classification: Unclassified
Component: Code (show other bugs)
Version: 8.2
Hardware: PC Windows 8.1
: P2 normal with 2 votes (vote)
Assignee: issues@ide
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-12-01 22:54 UTC by bht
Modified: 2017-06-08 08:02 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
IDE log (93.11 KB, text/plain)
2016-12-01 22:54 UTC, bht
Details
snapshot.nps from issue reporter (7.35 KB, application/octet-stream)
2016-12-01 22:55 UTC, bht
Details
UI log from issue reporter (1.57 MB, text/plain)
2016-12-01 22:57 UTC, bht
Details

Note You need to log in before you can comment on or make changes to this bug.
Description bht 2016-12-01 22:54:05 UTC
Created attachment 163120 [details]
IDE log

The IDE is locked up for about 100 seconds while it is trying "Downloading HTTP JavaDoc" which is perhaps failing.

I am attaching all data that I could extract from the issue reporter dialog.

I was just debugging some trivial code.

This happens to me multiple times per day.

Please refer to bug 204351
Comment 1 bht 2016-12-01 22:55:07 UTC
Created attachment 163121 [details]
snapshot.nps from issue reporter
Comment 2 bht 2016-12-01 22:57:30 UTC
Created attachment 163122 [details]
UI log from issue reporter

Please note that the issue reporter fails while I do not have any problem posting this from the same connection using a web browser.
Comment 3 Grimly 2017-06-08 08:02:48 UTC
I get the same issue and my IDE is completely locked when it happen.
I can prevent myself from locking by going to Tools > Options > Editor > Code Completion and unchecking the "Auto Popup Documentation Window" option.

This may happen because I'm working under a proxy that easily breaks connections in the end of the response.

I have not enough knowledge to reproduce this proxy behavior but what I would try is to setup a proxy that opens the HTTP+TCP connexions successfully, respond with part of the expected response and then abruptly timeout or close the TCP connexion.