Created attachment 28407 [details]
Thread dump

Unfortunately, I don't see any deadlock in given threads dump. Event queue
thread is waiting for swingbrowser thread, but swingbrowser thread in running,
trying to read url page through socket connection. Then there is second thread
which ends in the same native method of socket reading.

So IMHO this may signalize JDK problem, please jskrivanek could you try to run
tests on other JDKs available?

Also ccing deadlock experts in case I overlooked something.

I guess the problem started with
http://core.netbeans.org/source/browse/openide/src/org/openide/awt/Attic/SwingBrowserImpl.java?r1=1.29&r2=1.30

This Tim's commit mostly obsoleted the hack with filtered stream that postponed
opening of stream OTOH brought the possibility that RP tries to get the stream
(to find encoding or content type) while holding the SwingBrowserImpl lock and
someone  presses reload that is synchronized too and it will block the AWT thread. 

This can be a problem if you are debugging web app using this "browser" and set
breakpoint in the page. You would need to resume the app to proceed further in
stream reading but AWT is blocked. 

Radim found scenario how to easily reproduce it:

- set Swing HTML browser as default in Options
- create web application project
- toggle breakpoint at first line in index.jsp
- start debugging
- when browser appears click reload button and it freezes with the same thread dump.

workaround to scenario mentioned by Jirka is to kill debugged process (from
other place than the IDE)

*** Issue 75772 has been marked as a duplicate of this issue. ***

P2 (at the least).

Not to say don't fix this if possible, but how common a scenario is using the 
Swing browser for debugging?  The debugger could just check the value of the 
default browser from the system filesystem (no dependency needed), and if it 
sees the Swing browser, say "Sorry, debugging w/ the swing browser isn't 
supported."

Not saying it's the right choice, just an expedient option.  FWIW, the change 
there was to fix another AWT blockage, so any fix should try not to revert 
issue 41891.  Commit log message:

"#41891 - swing browser blocks AWT queue checking for proxy, etc. before it 
gets around to asynchronously loading the URL.  Read through the JEditorPane 
code for this and can't find any reason it should not be safe on a non EQ 
thread, and it solves the problem.

Also improved error reporting to not include exception class name, and no 
stack trace dialog if you type in a bad URL."

I don't agree with that "Sorry" option. We use Swing browser in automated tests
and such option would prevent us from using it. 

1) If this is important let's increase priority/escalate JDK bug #4714674:
JEditorPane.setPage(url) blocks AWT thread when HTTP protocol is used.

2) Re possible regression when fixing - did you write a test?

3) Threading and locking - I've read related code in JDK and core/openide many
times too and agree that it should be safe to call setPage from non-EDT. That's
the idea of Tim's original fix. OTOH the synchronization that was introduced
means the same problem as in original bug on the second attemp to load a URL or
reload the document (SwingBrowserImpl's RP hold the lock while connect to
internet and setURL or event handlers in EDT are trying to get it too).

Created attachment 34763 [details]
yet another deadlock

While trying to reproduce issue #85917 I get another similar deadlock. 
- call setPage() (for example select some menu item that opens browser)
- before it gets shown write some URL into location and hit Enter

EDT waits for SwingBrowserImpl lock to call setPage() asynchronously and thread
holding this lock call SU.iaw to get the stream.

Wrapping the test with 

        String oldPropValue =
System.getProperty("org.openide.awt.SwingBrowserImpl.do-not-block-awt");
        System.setProperty("org.openide.awt.SwingBrowserImpl.do-not-block-awt",
"true");

        System.setProperty("org.openide.awt.SwingBrowserImpl.do-not-block-awt",
(oldPropValue != null)? oldPropValue: "false");

should fix the first problem. The second one that I've reported today needs
different solution.

Jirka: can you confirm that it helps you to write tests (in fact this is what
our JPDA debugger does when it starts debugging)?

Checking in test/unit/src/org/openide/awt/SwingBrowserTest.java;
/shared/data/ccvs/repository/openide/awt/test/unit/src/org/openide/awt/SwingBrowserTest.java,v
 <--  SwingBrowserTest.java
initial revision: 1.1
done
Checking in src/org/openide/awt/SwingBrowserImpl.java;
/shared/data/ccvs/repository/openide/awt/src/org/openide/awt/SwingBrowserImpl.java,v
 <--  SwingBrowserImpl.java
new revision: 1.5; previous revision: 1.4
done

I verified it in build 20061003-1233 with JDK1.5.0_09 and JDK1.6.0. It works but
I found another issue 86384 (browser reloads page 3 times).

Unfortunately this fix causes race condition between SwingBrowserImpl and JEditorPane as SwingBrowser calls
doc.putProperty(Document.StreamDescriptionProperty, null); to force reload and then calls
swingBrowser.setPage(requestedURL); to set this property again in non AWT thread BUT JEditorPane accesses property
Document.StreamDescriptionProperty without checking if it is null in AWT thread. So moving some code in SwingBrowserImpl
to non AWT thread without possibility to synchronize with Swing in AWT thread is *NOT* solution. See issue #115293 for
NPE caused by this. Any idea how to fix this issue *WITHOUT* moving code in SwingBrowserImpl from AWT thread is welcome.

Never ending story which cannot be fixed without fixing http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4714674

*** Issue 115293 has been marked as a duplicate of this issue. ***

*** Issue 96199 has been marked as a duplicate of this issue. ***

moving opened issues from TM <= 6.1 to TM=Dev

According to JDK bug status fix was delivered in JDK 7 b27. I will check.

closing - patches welcome