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.
Build: NetBeans IDE Dev (Build EaselCSS-239-on-20120618) VM: Java HotSpot(TM) Client VM, 22.0-b10, Java(TM) SE Runtime Environment, 1.7.0_02-b13 OS: Windows XP User Comments: pjiricka: Closing a Chrome tab. Stacktrace: java.lang.AssertionError at org.netbeans.modules.extbrowser.plugins.chrome.WebKitDebuggingTransport.sendCommand(WebKitDebuggingTransport.java:61) at org.netbeans.modules.web.webkit.debugging.TransportHelper.sendBlockingCommand(TransportHelper.java:91) at org.netbeans.modules.web.webkit.debugging.api.Runtime.evaluate(Runtime.java:106) at org.netbeans.modules.web.inspect.webkit.WebKitPageModel.invokeInAllDocuments(WebKitPageModel.java:451) at org.netbeans.modules.web.inspect.webkit.WebKitPageModel$WebPaneSynchronizer.updateHighlight(WebKitPageModel.java:513) at org.netbeans.modules.web.inspect.webkit.WebKitPageModel$WebPaneSynchronizer.propertyChange(WebKitPageModel.java:497)
Created attachment 121012 [details] stacktrace
Petr, is this reproducible? It looks like Chrome browser tab was closed and web.inspect.ui.DomPanel have not realized that yet and keeps sending requests. Honza do you think this should be handled on your side or somewhere else?
> Honza do you think this should be handled on your side or somewhere else? I saw this exception few times. I will check whether I am able to resolve it on my side.
Created attachment 122672 [details] stacktrace Opened Twitter Bootstrap example sent to mailing list.
Created attachment 122900 [details] stacktrace I closed Chrome after debugging.
Fixed by http://hg.netbeans.org/web-main/rev/b6303a875f2b
Honza, I was just curious how you are using TransportStateException. In case of this fix should not the WebPaneSynchronizer listener be completely removed/disable on first "TransportStateException"? Or is there a different mechanism which stops events from being fired again? Sorry if it is naive question - I only looked at the changeset. Thanks.
> In case of this fix should not the WebPaneSynchronizer listener be completely > removed/disable on first "TransportStateException"? Or is there a different > mechanism which stops events from being fired again? Sorry if it is naive > question - I only looked at the changeset. Thanks. It is not necessary to unregister the listener from the corresponding page model because the whole PageModel instance will die once the corresponding browser pane is closed/detached. And yes, there is a different mechanism which stops the events. PageInspectorImpl fires PROP_MODEL event when the page-inspection is finished. So, all clients are supposed to stop touching the old page model when this happens. The exception is thrown by events triggered before the transport become invalid but whose processing was not finished before the detach. Note that this can be even several seconds after the detach. The typical scenario is sendBlockingCommand1 sendBlockingCommand2 The first command is sent before detach, but the response is never obtained because of the detach. Hence, it takes 5s for sendBlockingCommand1 to timeout. After that sendBlockingCommand2 is invoked and it results in TransportStateException.