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 245227

Summary: NetBeans Connector for Chrome not working on Mac OSX El Capitain, Chrome 46 Netbeans 8.0.2
Product: ide Reporter: nghianja
Component: ExtbrowserAssignee: Jan Stola <jstola>
Status: REOPENED ---    
Severity: normal CC: noudard
Priority: P3    
Version: 8.0.2   
Hardware: Macintosh   
OS: Mac OS X   
Issue Type: DEFECT Exception Reporter:

Description nghianja 2014-06-25 08:30:13 UTC
I have noticed bugs #226993 and #244047 may be similar bug log entries but since I cannot find any resolution from them, I thought I should do my part and contribute my scenario and findings here.

I have installed the latest Chrome browser and NetBeans 8.0 on my MacBook Pro upgraded to OSX 10.9.3. However, the NetBeans Connector extension on my Chrome fails to redirect to my HTML5 application on the embedded web-server (http://localhost:8383) and simply just shows a blank screen.

After performing several troubleshooting procedures, my friend and I found that the JavaScript in the extension is trying to connect to ws://127.0.0.1:8008/. When we ran the command ‘netstat -na | grep 8008′, we noticed that Mavericks assigned the system’s current IP to the port instead, eg. 192.168.1.106:8008.
Comment 1 Jan Stola 2015-03-23 16:53:56 UTC
Are you still able to reproduce this issue? If so, could you, please, provide more details? The URL of the blank screen that you see is something like file:///path/to/some/temp/folder/blank<aLotOfNumbers>.html, right? I guess that there is no yellow strip saying 'NetBeans Connector is debugging this tab', correct? What happens when you open Chrome Developer tools for this tab and execute the following script there:

var socket = new WebSocket("ws://127.0.0.1:8008/")
socket.onerror = function(e) {
  console.log('Error:');
  console.log(e.name);
  console.log(e.message);
};
socket.onopen = function() {
  console.log('Opened!');
  socket.send(JSON.stringify({
    message: 'ready',
    version: '1.7.4'
  }));
  socket.send(JSON.stringify({
    message: 'init',
    url: 'file:///C:/Users/jstola/AppData/Local/Temp/blank997507126187845144.html',
    tabId: 12345,
    version: '1.7.4'
  }));
};
socket.onclose = function() {
  console.log('Closed!');
};
socket.onmessage = function(e) {
  console.log('Received:'+e.data);
};
Comment 2 Jan Stola 2015-03-23 16:54:49 UTC
Please, replace file:///C:/Users/jstola/AppData/Local/Temp/blank997507126187845144.html
by the URL of the blank page in the script above.
Comment 3 nghianja 2015-03-24 16:00:04 UTC
Hi Jan,

As I have updated my system to Yosemite and Netbeans 8.0, I am not able to test the bug again. The bug is also not observed in the new Netbeans so there is no more data I can provide you. Thank you very much for your help and I think you can close this issue.

Best Regards,
James Ng
Comment 4 Jan Stola 2015-03-25 07:54:01 UTC
Thank you for your quick response. I am closing this issue as "not reproducible". Feel free to reopen it if you encounter it again but do not forget to provide more details then. Thank you in advance.
Comment 5 noudard 2015-10-31 10:41:42 UTC
Hello,
When I try to launch my website (chrome with netbeans connector),I get a blank page like file:///var/folders/xm/znn6syj16037xnskwpv8x40c0000gn/T/blank3947671498816448661.html

The content of this web page is : 
<html :netbeans_temporary="true"></html>

When I open Chrome Developer tools and debug the netbeans connector, i can see "WebSocket connection to 'ws://127.0.0.1:8008/' failed: Error in connection establishment: net::ERR_CONNECTION_REFUSED"


If I try to launch my website (chrome whithout netbeans connector) my website works fine and the url is : http://localhost:8383/testproject/index.html

Some informations:
NetBeans Connector 1.1.5

Google Chrome	46.0.2490.80 (Build officiel) (64 bits)
Révision	c6bfd1395b9449cb59180d45944a8cb56799bd9c-refs/branch-heads/2490@{#549}

Mac OS X El Captain version 10.11

Product Version: NetBeans IDE 8.0.2 (Build 201411181905)
Updates: NetBeans IDE is updated to version NetBeans 8.0.2 Patch 2
Java: 1.8.0_60; Java HotSpot(TM) 64-Bit Server VM 25.60-b23
Runtime: Java(TM) SE Runtime Environment 1.8.0_60-b27
System: Mac OS X version 10.11 running on x86_64; UTF-8; fr_FR (nb)
User directory: /Users/nico/Library/Application Support/NetBeans/8.0.1
Cache directory: /Users/nico/Library/Caches/NetBeans/8.0.1

Can you help me ?
Many Thanks
Nico
Comment 6 Jan Stola 2015-10-31 10:52:03 UTC
NetBeans Connector attempts to establish a connection with NetBeans IDE on port 8008 and this fails. NetBeans IDE was probably unable to start the server socket accepting these connection on port 8008. Could you, please, check IDE Log of NetBeans (using View > IDE Log menu item) if there is any exception/message about this failure? Thank you in advance.
Comment 7 noudard 2015-11-02 09:46:28 UTC
Hello,
There are some informations about proxy but no information about this failure in IDE log.

INFO [org.netbeans.core.netigso.Netigso]: bundle org.eclipse.osgi@3.9.1.v20140110-1610 started
INFO [org.netbeans.core.network.proxy.NetworkProxyReloader]: System network proxy resolver: Mac
INFO [org.netbeans.core.network.proxy.NetworkProxyReloader]: System network proxy reloading failed! Trying fallback resolver.
INFO [org.netbeans.core.network.proxy.fallback.FallbackNetworkProxy]: Fallback system proxy resolver: no http_proxy variable found
INFO [org.netbeans.core.network.proxy.NetworkProxyReloader]: System network proxy reloading succeeded. Fallback provider was successful.
INFO [org.netbeans.core.network.proxy.NetworkProxyReloader]: System network proxy - mode: direct
INFO [org.netbeans.core.network.proxy.NetworkProxyReloader]: System network proxy: fell to default (correct if direct mode went before)
WARNING [org.openide.filesystems.MIMESupport]: org.netbeans.modules.nodejs.ScriptResolver's constructor should call super(String...) with list of resolvable MIME types.
INFO [org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater]: Resolving dependencies took: 31 ms
INFO [org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater]: Complete indexing of 0 binary roots took: 0 ms
Comment 8 timmaher 2016-04-01 16:06:30 UTC
This has resurfaced. I have just "upgraded" to El Capitan and the Chrome connector fails as port 8008 is already occupied, this time by tcp46 that is doing a listen.
The output of lost is thus:-
sudo lsof -i -P|grep 8008
httpd      494            root    8u  IPv6 0xb8c218e1cdc31eed      0t0  TCP *:8008 (LISTEN)
httpd      501            _www    8u  IPv6 0xb8c218e1cdc31eed      0t0  TCP *:8008 (LISTEN)
httpd      502            _www    8u  IPv6 0xb8c218e1cdc31eed      0t0  TCP *:8008 (LISTEN)
httpd      503            _www    8u  IPv6 0xb8c218e1cdc31eed      0t0  TCP *:8008 (LISTEN)
httpd      504            _www    8u  IPv6 0xb8c218e1cdc31eed      0t0  TCP *:8008 (LISTEN)
httpd      505            _www    8u  IPv6 0xb8c218e1cdc31eed      0t0  TCP *:8008 (LISTEN)

Perhaps there is some configuration conflict that Apple has introduced and NetBeans connector designers are not yet aware of?
Comment 9 steadyonabix 2018-01-16 16:17:36 UTC
I have reopened this issue as it seems to be a regression:

I have just upgraded my MAC to High Sierra and have this same problem. Clicking on run produces a blank page. I didn't have Netbeans installed previously, I have just installed it to learn AngularJS and would like to be able to debug my code.

I eventually see this INFO in the Netbeans log telling me of the timeout trying to connect the debugger:

INFO [org.netbeans.api.debugger.jpda.AttachingDICookie]: Attaching Connector = com.sun.jdi.SocketAttach (defaults: timeout=, hostname=Mac2802.local, port=), arguments = {timeout=timeout=, hostname=hostname=Mac2802.local, port=port=8008}
java.net.ConnectException: Operation timed out (Connection timed out)
	at java.net.PlainSocketImpl.socketConnect(Native Method)
	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
	at java.net.Socket.connect(Socket.java:589)
	at com.sun.tools.jdi.SocketTransportService.attach(SocketTransportService.java:222)
	at com.sun.tools.jdi.GenericAttachingConnector.attach(GenericAttachingConnector.java:116)
	at com.sun.tools.jdi.SocketAttachingConnector.attach(SocketAttachingConnector.java:90)
[catch] at org.netbeans.api.debugger.jpda.AttachingDICookie.getVirtualMachine(AttachingDICookie.java:231)
	at org.netbeans.modules.debugger.jpda.actions.StartActionProvider.doStartDebugger(StartActionProvider.java:188)
	at org.netbeans.modules.debugger.jpda.actions.StartActionProvider.access$200(StartActionProvider.java:80)
	at org.netbeans.modules.debugger.jpda.actions.StartActionProvider$1.run(StartActionProvider.java:165)
	at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1443)
	at org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:68)
	at org.openide.util.lookup.Lookups.executeWith(Lookups.java:303)
	at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2058)
INFO [org.netbeans.api.debugger.jpda.AttachingDICookie]: Attaching Connector = com.sun.jdi.SocketAttach (defaults: timeout=, hostname=Mac2802.local, port=), arguments = {timeout=timeout=, hostname=hostname=Mac2802.local, port=port=8008}
java.net.ConnectException: Operation timed out (Connection timed out)
	at java.net.PlainSocketImpl.socketConnect(Native Method)
	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
	at java.net.Socket.connect(Socket.java:589)
	at com.sun.tools.jdi.SocketTransportService.attach(SocketTransportService.java:222)
	at com.sun.tools.jdi.GenericAttachingConnector.attach(GenericAttachingConnector.java:116)
	at com.sun.tools.jdi.SocketAttachingConnector.attach(SocketAttachingConnector.java:90)
[catch] at org.netbeans.api.debugger.jpda.AttachingDICookie.getVirtualMachine(AttachingDICookie.java:231)
	at org.netbeans.modules.debugger.jpda.actions.StartActionProvider.doStartDebugger(StartActionProvider.java:188)
	at org.netbeans.modules.debugger.jpda.actions.StartActionProvider.access$200(StartActionProvider.java:80)
	at org.netbeans.modules.debugger.jpda.actions.StartActionProvider$1.run(StartActionProvider.java:165)
	at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1443)
	at org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:68)
	at org.openide.util.lookup.Lookups.executeWith(Lookups.java:303)
	at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2058)


My OS is: High Sierra 10.13.2
Chrome Plugin: 1.1.5
Netbeans: 8.2

Default Browser is set to Chrome with Netbeans Connector

So clicking on the run button does open Chrome but with a blank page and a funky file url like - file:///private/var/folders/4l/3gq9477n6_952q1ztvz5ngdckcdyx4/T/blank2898410126737509298.html

That file contains the single line - <html :netbeans_temporary="true"></html>

Any advice on how to get past this would be appreciated

Thanks
Comment 10 radoslaw.kojdecki 2018-01-18 07:33:02 UTC
(In reply to steadyonabix from comment #9)
> I have reopened this issue as it seems to be a regression:
> 
> I have just upgraded my MAC to High Sierra and have this same problem.
> Clicking on run produces a blank page. I didn't have Netbeans installed
> previously, I have just installed it to learn AngularJS and would like to be
> able to debug my code.
> 

I have the same issue just after upgrading to High Sierra.

Chrome: Wersja 63.0.3239.132 (Oficjalna wersja) (64-bitowa)

Netbeans :

Product Version: NetBeans IDE 8.2 (Build 201609300101)
Updates: NetBeans IDE is updated to version NetBeans 8.2 Patch 2
Java: 1.8.0_112; Java HotSpot(TM) 64-Bit Server VM 25.112-b16
Runtime: Java(TM) SE Runtime Environment 1.8.0_112-b16
System: Mac OS X version 10.13.2 running on x86_64; UTF-8; pl_PL (nb)


regards.,


Radoslaw Kojdecki
Comment 11 radoslaw.kojdecki 2018-01-18 07:46:29 UTC
I'm attaching the Wireshark dump of communication on port 8080 : 

Chrome -> Netbeans :
00000000  81 c9 ad 83 14 ed d6 a1  79 88 de f0 75 8a c8 a1   ........ y...u...
00000010  2e cf c4 ed 7d 99 8f af  36 98 df ef 36 d7 8f e0   ....}... 6...6...
00000020  7c 9f c2 ee 71 d7 82 ac  7a 88 da f7 75 8f 82 a1   |...q... z...u...
00000030  38 cf d9 e2 76 a4 c9 a1  2e dc 9a b0 38 cf db e6   8...v... ....8...
00000040  66 9e c4 ec 7a cf 97 a1  25 c3 95 ad 25 cf d0      f...z... %...%..


Netbeans -> Chrome reply :
    00000000  81 45 7b 22 74 61 62 49  64 22 3a 31 37 33 2c 22   .E{"tabI d":173,"
    00000010  6d 65 73 73 61 67 65 22  3a 22 69 6e 69 74 22 2c   message" :"init",
    00000020  22 76 65 72 73 69 6f 6e  22 3a 22 38 2e 31 22 2c   "version ":"8.1",
    00000030  22 73 74 61 74 75 73 22  3a 22 6e 6f 74 61 63 63   "status" :"notacc
    00000040  65 70 74 65 64 22 7d                               epted"}
Comment 12 radoslaw.kojdecki 2018-01-18 07:47:19 UTC
Of course port 8008 :)
Comment 13 LukeyT 2018-11-12 11:56:14 UTC
I also experience this issue (upgraded to Mac OS Mojave).  Same problem.  Note that a workaround of setting the browser in netbeans to Chrome (without netbeans connector), followed by clicking the netbeans icon in the toolbar of the browser when it appears, and then choosing 'Debug in netbeans' does seem to work.

However this is a regression as worked in previous Mac OS with the same Chrome version.
Comment 14 pmkpmk 2018-11-24 06:08:51 UTC
I'm getting this same issue. I'm also using Mojave. I tried some of the workaround suggested, but I don't see the difference between setting the Web Browser in preferences to Chrome vs Default System Browser - which is Chrome. So, that didn't help either. 

I'm using
Product Version: NetBeans IDE 8.2 (Build 201609300101)
Updates: NetBeans IDE is updated to version NetBeans 8.2 Patch 2
Java: 1.8.0_181; Java HotSpot(TM) 64-Bit Server 
Runtime: Java(TM) SE Runtime Environment 1.8.0_181-b13
System: Mac OS X version 10.14.1 running on x86_64

Chrome is up to date with Version 70.0.3538.110 (Official Build) (64-bit)

I'm using Netbeans Connector 1.1.5.

If I create a brand new HTML5/Javascript Application project without any Tools, and Run index.html, I get this issue, so it should be easy to re-produce.

The Netbeans log doesn't have any errors. 

Looking for port 8008 gives:
java      22639    name  123u  IPv6 0x_id      0t0  TCP localhost:8008->localhost:53330 (ESTABLISHED)
java      22639    name  417u  IPv6 0x_id      0t0  TCP localhost:8008 (LISTEN)
Google    24302    name  138u  IPv4 0x_id      0t0  TCP localhost:53330->localhost:8008 (ESTABLISHED)
 
Any ideas how I can proceed?
Comment 15 rhacooper 2019-02-08 21:36:01 UTC
I've been having the same problem on a Mac,  I've chased this down to the following.

1) Netbeans create a debug session and dummy web page with name like -

    file:///var/folders/4l/3*2.html

   and regisiters the debug session under name of the dummy web page. 

2) Netbeans fires up Chrome and attempts to initialise the connector sending the location of the dummy web page.

3) The Chrome Connector fires up and acknowleges the connection by passing back the name of the dummy web page to netbeans.

However the name passed back in 3) has been changed (somehwhere) to -

    file:///private/var/folder/41/3*2.html

when netbeans get the acknowlegement it attempts to find the session it stored but because the name has had '/private' inserted the lookup fails and netbeans refuses to debug.

I hacked the code to remove the '/private' just prior to the lookup in 3) and NetBeans will connect and debug as normal.  This however is not a fix for the problem, what is needed is for someone with domain knowlege to investigate why the name of the dummy html location is changing during the initialisation handshake round trip.
Comment 16 Geertjan Wielenga 2019-02-25 21:20:36 UTC
Hi rhacooper, can you contact me at geertjan dot wielenga at oracle dot com? I'm trying to work on this and could use the insights you outline above.
Comment 17 Geertjan Wielenga 2019-02-26 12:30:12 UTC
Some thoughts from Jan Stola, one of the developers of the Chrome Connector, sent separately to me: "rhacooper seems to describe the problem quite well. When some page is inspected from NetBeans then NetBeans opens some dummy page and remembers its name/URL. When NetBeans Chrome extension sees a new page opened in Chrome then it attempts to contact NetBeans (on some port) with a message describing the URL of the page opened. If NetBeans recognizes the page as the one that should be inspected then some magic happens and the inspection starts. Unfortunately, this handshake seems to be broken. The URL opened in the browser has this strange "/private" prefix (for an unknown reason). So, the page is not recognized and the inspection is not started.

As the first step, I suggest you to debug https://github.com/apache/incubator-netbeans/blob/master/webcommon/extbrowser.chrome/src/org/netbeans/modules/extbrowser/plugins/ExternalBrowserPlugin.java I believe that register() method is called with the URL that NetBeans attempts to open (i.e. the one without the strange private prefix) and then handleInit() method is called with a message that contains the URL with the private prefix (which fails to find a match in getAwaitingPair()). You can either workaround the issue here or you can try to figure out the root of the strange prefix by trying to play with the NetBeans Chrome extension."
Comment 18 hohepa 2019-02-27 00:01:24 UTC
The standard directory structure on Mac OS X includes private/ at the root level: 

private/etc
private/tmp
private/var

and symbolic links to these directories are created at the root level

etc --> private/etc
tmp --> private/tmp
var --> private/var
Comment 19 Geertjan Wielenga 2019-02-27 20:31:18 UTC
Yes, discovered this as well, but how does this impact this and what are the implications?
Comment 20 Geertjan Wielenga 2019-02-27 20:47:43 UTC
Also, you fixed it by patching the sources to ignore "/private" part - how and where did you do this, maybe we should take that and polish and integrate it?
Comment 21 inhack20 2019-05-13 16:05:48 UTC
(In reply to rhacooper from comment #15)
> I've been having the same problem on a Mac,  I've chased this down to the
> following.
> 
> 1) Netbeans create a debug session and dummy web page with name like -
> 
>     file:///var/folders/4l/3*2.html
> 
>    and regisiters the debug session under name of the dummy web page. 
> 
> 2) Netbeans fires up Chrome and attempts to initialise the connector sending
> the location of the dummy web page.
> 
> 3) The Chrome Connector fires up and acknowleges the connection by passing
> back the name of the dummy web page to netbeans.
> 
> However the name passed back in 3) has been changed (somehwhere) to -
> 
>     file:///private/var/folder/41/3*2.html
> 
> when netbeans get the acknowlegement it attempts to find the session it
> stored but because the name has had '/private' inserted the lookup fails and
> netbeans refuses to debug.
> 
> I hacked the code to remove the '/private' just prior to the lookup in 3)
> and NetBeans will connect and debug as normal.  This however is not a fix
> for the problem, what is needed is for someone with domain knowlege to
> investigate why the name of the dummy html location is changing during the
> initialisation handshake round trip.

Please tell us how you solved to implement the patch locally. Please, I would appreciate it.