Bug 221739 - Inspect mode takes some time to be ready after page is reloaded
Inspect mode takes some time to be ready after page is reloaded
Status: VERIFIED FIXED
Product: web
Classification: Unclassified
Component: Inspection
7.3
All All
: P2 (vote)
: 7.3
Assigned To: Jan Stola
issues@web
: PERFORMANCE
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-08 15:47 UTC by Vladimir Riha
Modified: 2012-11-12 07:14 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
profiler snapshot (17.10 KB, application/octet-stream)
2012-11-08 15:47 UTC, Vladimir Riha
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Vladimir Riha 2012-11-08 15:47:33 UTC
Created attachment 127407 [details]
profiler snapshot

I have this simple page:

...
<body>
        <div>TODO write content</div>
        <img src="rabbit1.jpg" width="100" height="100"/> <p>Donec id elit non mi porta gravida at eget metus. Fusce dapibus, tellus ac cursus commodo, tortor mauris condimentum nibh, ut fermentum massa justo sit amet risus. Etiam porta sem malesuada magna mollis euismod. Donec sed odio dui. </p>
    </body>
...


Now:
- run it in Chrome
- start inspect mode
- reload the page (use Auto Refresh ...)
=> it takes about ~2-4 seconds until inspect mode starts to highlight elements again (and select them). I even removed the img but no improvements.

It works fast with embedded browser. The attached snapshot was from a moment between I hit Reload and it ends in a moment when Inspect mode started to work again. IDE logs shows nothing. This used to be fast as with embedded browser and for a few seconds looks like broken, so in my opinion P2. If you need any more logs etc., let me know.




Product Version: NetBeans IDE Dev (Build web-main-9156-on-20121108) and 9158
Java: 1.7.0_10-ea; Java HotSpot(TM) Client VM 23.6-b04
Runtime: Java(TM) SE Runtime Environment 1.7.0_10-ea-b15
System: Linux version 3.2.0-32-generic-pae running on i386; UTF-8; en_US (nb)
Comment 1 Jan Stola 2012-11-10 18:01:09 UTC
I was able to reproduce this issue. I took a thread dump while the inspection was not working and it showed the following thread:

"org.netbeans.modules.web.inspect.webkit.WebKitPageModel"
java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:196)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos
   (AbstractQueuedSynchronizer.java:1011)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos
   (AbstractQueuedSynchronizer.java:1303)
at java.util.concurrent.Semaphore.tryAcquire(Semaphore.java:383)
at o.n.m.web.webkit.debugging.TransportHelper$Handle.waitForResponse
   (TransportHelper.java:210)
at o.n.m.web.webkit.debugging.TransportHelper.sendBlockingCommand
   (TransportHelper.java:121)
at o.n.m.web.webkit.debugging.api.dom.DOM.resolveNode(DOM.java:420)
at o.n.m.web.inspect.webkit.WebKitPageModel$WebPaneSynchronizer.updateSelection
   (WebKitPageModel.java:842)
at o.n.m.web.inspect.webkit.WebKitPageModel$WebPaneSynchronizer.updateSelection
   (WebKitPageModel.java:830)
at o.n.m.web.inspect.webkit.WebKitPageModel$WebPaneSynchronizer.updateSelection
   (WebKitPageModel.java:826)
at o.n.m.web.inspect.webkit.WebKitPageModel$WebPaneSynchronizer.propertyChange
   (WebKitPageModel.java:753)
at java.beans.PropertyChangeSupport.firePropertyChange
   (PropertyChangeSupport.java:339)
at java.beans.PropertyChangeSupport.firePropertyChange
   (PropertyChangeSupport.java:276)
at org.netbeans.modules.web.inspect.PageModel.firePropertyChange
   (PageModel.java:237)
at o.n.m.web.inspect.webkit.WebKitPageModel.setSelectedNodes
   (WebKitPageModel.java:500)
at o.n.m.html.navigator.HtmlNavigatorPanelUI.pageModelDocumentChanged
   (HtmlNavigatorPanelUI.java:243)
at o.n.m.html.navigator.HtmlNavigatorPanelUI.access$200
   (HtmlNavigatorPanelUI.java:117)
at o.n.m.html.navigator.HtmlNavigatorPanelUI$2.propertyChange
   (HtmlNavigatorPanelUI.java:167)
at java.beans.PropertyChangeSupport.firePropertyChange
   (PropertyChangeSupport.java:339)
at java.beans.PropertyChangeSupport.firePropertyChange
   (PropertyChangeSupport.java:276)
at org.netbeans.modules.web.inspect.PageModel.firePropertyChange
   (PageModel.java:237)
at org.netbeans.modules.web.inspect.webkit.WebKitPageModel.access$600
   (WebKitPageModel.java:72)
at org.netbeans.modules.web.inspect.webkit.WebKitPageModel$1$1.run
   (WebKitPageModel.java:306)
at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1454)
at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2036)

The thread was blocked in the resolution of webKit node to JavaScript node. The log showed that this resolution fails, i.e., no response is returned for this request (and it takes ~5s till we give up waiting).

The detailed investigation of the code on the stack-trace disclosed that the resolution is attempted for a node that is no longer valid, i.e., for a node from the old version of the document. This seems to be the reason why the resolution fails.

The obsolete node is passed to PageModel from HtmlNavigatorPanelUI.pageModelDocumentChanged(). I have filled issue 221879 against HTML Navigator regarding this problem. On the other hand, even if issue 221879, it still may happen is some special cases that an obsolete node is passed to PageModel. Hence, I also modified setSelectedNode() method to handle this situation more gracefully.

Modified file: http://hg.netbeans.org/web-main/rev/0c257265b122
Comment 2 Vladimir Riha 2012-11-12 07:14:20 UTC
Thanks, now it is much faster


Product Version: NetBeans IDE Dev (Build 201211120001)
Java: 1.7.0_10-ea; Java HotSpot(TM) Client VM 23.6-b04
Runtime: Java(TM) SE Runtime Environment 1.7.0_10-ea-b15
System: Linux version 3.2.0-32-generic-pae running on i386; UTF-8; en_US (nb)


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo