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.
Summary: | IllegalStateException: Trying to set lookup org.openide.util.Lookup$Empty@44b01d43 but there already is [Ljava.lang.Object;@2d311249 for component: org.netbeans.core.HtmlBrowserComponent[Web Browser,0 | ||
---|---|---|---|
Product: | platform | Reporter: | Petr Jiricka <pjiricka> |
Component: | Embedded Browser | Assignee: | David Konecny <dkonecny> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | ads, dkonecny, johnjullion, jstola, pjiricka, saubrecht |
Priority: | P2 | ||
Version: | 7.2 | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | 185828 |
Attachments: |
stacktrace
stacktrace stacktrace stacktrace |
Description
Petr Jiricka
2012-03-13 15:11:50 UTC
Created attachment 116675 [details]
stacktrace
Lookup is changed via associateLookup() call which is added by David. But it seems the issue is generic : it is race condition. I don't see any other reason to have lookup initialized when browserComponent is null. It could be a problem of deserialization (if it is called outside of AWT thread). browserComponent is initialized on the deserialization along with lookup. But setURLAndOpen() is called inside AWT thread where browserComponent is null. It means that browserComponent is initialized twice : on deserialization and inside setURLAndOpen() and this is bug. So the problem is not lookup itself. *** Bug 209585 has been marked as a duplicate of this bug. *** I can confirm that this happened after IDE startup when embedded browser was open. So in which component this needs to be fixed? That's the bug inside org.netbeans.core.HtmlBrowserComponent class, o.n.core module. I'm not sure what component exactly should be used. Then I guess this is Standa's. Created attachment 117270 [details]
stacktrace
Running a client-side project after closing the embedded browser window.
*** Bug 208803 has been marked as a duplicate of this bug. *** Created attachment 119051 [details]
stacktrace
opening IDE with internal javafx browser open
-> P2. Created attachment 119330 [details]
stacktrace
This is very annoying as it happens too often. To reproduce the issue follow these steps: * open a file in embedded browser * close the embedded browser * open a file in embedded browser Second opening of embedded browser throws attached exception. It look like first closing of embedded browser does not actually close the TopComponent - it closed embedded browser component but owning TopComponent gets what? gets hidden? I'm workarounding this by enforcing new TopComponent creation. Can be right fix, can be wrong. Standa, could you review please? Thanks. e3169ac1eb16 > I'm workarounding this by enforcing new TopComponent creation. Can be > right fix, can be wrong. David, I am reopening this issue because this doesn't seem to be the right fix. First of all, your workaround does nothing when the HtmlBrowserComponent is not opened through WebBrowserPane. The following steps lead to the same exception even with your change applied: * Open Tools > Online Docs and Support * close Online Docs and Support * Open Tools > Online Docs and Support again Moreover, the empty body of your componentClosed() fails to trigger actions associated with the closure of HtmlBrowserComponent like end of debugging and page inspection. > Second opening of embedded browser throws attached exception. It look like > first closing of embedded browser does not actually close the TopComponent > - it closed embedded browser component but owning TopComponent gets what? > gets hidden? There seems to be a confusion between closure and destruction/disposal. When HtmlBrowserComponent is closed then the corresponding HtmlBrowser is disposed (i.e., not reused when HtmlBrowserComponent is opened again). In other words, a new HtmlBrowser is created whenever HtmlBrowserComponent is opened. The changes that you introduced with the lookup changes are not compatible with this life-cycle. You call associateLookup() whenever HtmlBrowser is created, i.e., whenever HtmlBrowserComponent is opened. This is the root of the exception. associateLookup() can be called just once. Hence, it throws the attached exception when HtmlBrowserComponent is opened for the second time. I believe that the right fix is the rewrite of the handling of HtmlBrowserComponent's lookup. You should make sure that associateLookup() is called just once. For example, you can call associateLookup(someProxyLookup) is constructor and update the content of 'someProxyLookup' in componentActivated() and componentClosed() methods (that instantiate/dispose HtmlBrowser). I've made some changes in 72e70a1 that take care of the associateLookup() problem - it is always called just once now. Not sure what should happen in HtmlBrowserComponent.componentClosed() though. > I've made some changes in 72e70a1 that take care of the associateLookup() > problem - it is always called just once now. I see. Hence, some parts of my previous comment are no longer valid after this change, I guess. > Not sure what should happen in HtmlBrowserComponent.componentClosed() though. I added super.componentClosed() into WebBrowserPane$2 (that extends HTMLBrowserComponent) to trigger shutdown of webkit debugging and page inspection (see http://hg.netbeans.org/web-main/rev/35aaccea7dc4 ) and everything I checked seems to work fine now. Thanks for fixing it properly guys. Should the issue be closed now? Issue was not closed when it was fixed. Integrated into 'main-golden', will be available in build *201209031048* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/e3169ac1eb16 User: David Konecny <dkonecny@netbeans.org> Log: #209524 - IllegalStateException: Trying to set lookup org.openide.util.Lookup |