Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v6.7.0 V8_inspector link does not work on macOS 10.12 Chrome 53 #8846

Closed
JLHwung opened this issue Sep 29, 2016 · 20 comments
Closed

v6.7.0 V8_inspector link does not work on macOS 10.12 Chrome 53 #8846

JLHwung opened this issue Sep 29, 2016 · 20 comments
Labels
inspector Issues and PRs related to the V8 inspector protocol

Comments

@JLHwung
Copy link
Contributor

JLHwung commented Sep 29, 2016

  • Version: v6.7.0
  • Platform: Darwin jh.local 16.0.0 Darwin Kernel Version 16.0.0: Mon Aug 29 17:56:20 PDT 2016; root:xnu-3789.1.32~3/RELEASE_X86_64 x86_64
  • Subsystem: V8_inspector
  • Chrome: 53.0.2785.116

Here is a simple forever node daemon

echo "setInterval(() => console.log('Hello world'), 1e3)" > index.js

node --inspect index.js will show

To start debugging, open the following URL in Chrome:
    chrome-devtools://devtools/remote/serve_file/@60cd6e859b9f557d2312f5bf532f6aec5f284980/inspector.html?experiments=true&v8only=true&ws=localhost:9229/node

However, when opening this link on Chrome 53.0.2785.116, the left sidebar is empty. one cannot see any files (index.js) on the panel.

screen shot 2016-09-29 at 20 22 39

Opening this link on Chrome Canary 55 looks good to me, though.
image

I use --inspect daily and AFAIK Chrome 53 works good on v6.6.0.

@JLHwung JLHwung changed the title v6.7.0 V8_inspector link does not work on Chrome 53 v6.7.0 V8_inspector link does not work on macOS 10.12 Chrome 53 Sep 29, 2016
@targos targos added the inspector Issues and PRs related to the V8 inspector protocol label Sep 29, 2016
@targos
Copy link
Member

targos commented Sep 29, 2016

/cc @nodejs/v8-inspector

@evanlucas
Copy link
Contributor

hm, I'm unable to reproduce on the same OS and Chrome

@fhinkel
Copy link
Member

fhinkel commented Sep 29, 2016

I can reproduce the problem.

But it works if I run with break on first line:
node --inspect --debug-brk index.js.

Manually opening the file as suggested with Cmd+P also works.

@gibfahn
Copy link
Member

gibfahn commented Sep 29, 2016

Also unable to reproduce.

@JLHwung
Copy link
Contributor Author

JLHwung commented Sep 29, 2016

@fhinkel I do a reset settings on Google Chrome and now it works both on --inspect and --inspect --debug-brk. So it's likely due to Chrome configuration issues.

I think this problem can be closed if @fhinkel confirms no reproduction after reset.

@Taivas
Copy link

Taivas commented Sep 30, 2016

@JLHwung I got the same problem and It works! Thank you man!

@Taivas
Copy link

Taivas commented Sep 30, 2016

So sad it happened again 10 min later. So reset settings is not a long term solution. Also I can reproduce @JLHwung 's case.

@JLHwung
Copy link
Contributor Author

JLHwung commented Sep 30, 2016

I don't realize I can debug v8-inspector front-end until I press command+j accidentally on v8-inspector. It feels like Inception somehow but finally the problem is clear:

image

It seems that v8-inspector can not establish connection to localhost:9229/node due to a SSL protocol problem.

@fhinkel settings reset solves my problem at first but after couple of hours it happens again. No idea how to trigger this problem.

@Taivas I am more than happy to help you but it seems configuration reset is not a perfect workaround.

@fhinkel
Copy link
Member

fhinkel commented Sep 30, 2016

Have you tried running with with --debug-brk instead of resetting the config?

@JLHwung
Copy link
Contributor Author

JLHwung commented Sep 30, 2016

@fhinkel I tried but got no luck. Still SSL Protocol issue. What does your console on v8-inspector complain on --inspect?

@eugeneo
Copy link
Contributor

eugeneo commented Sep 30, 2016

CC: @ak239 Any thoughts?

@spamguy
Copy link

spamguy commented Oct 8, 2016

Seeing the same thing, with the same setup. I downgraded to v6.6.0, since @JLHwung mentioned earlier success with it, but no go. Meanwhile, my home computer (also a Mac on 10.12 + Chrome 53 + node 6.7.0) handles --inspect fine. There's an unknown variable in play here.

@JLHwung
Copy link
Contributor Author

JLHwung commented Oct 9, 2016

@spamguy I just try downgrading to 6.6.0 and same thing happens. As @fhinkel get work with --debug-brk, have you tried --debug-brk? mine also see the SSL Protocol Error on --debug-brk.

@spamguy
Copy link

spamguy commented Oct 9, 2016

--debug-brk made no difference. But, the suggestion to use Chrome Canary did work.

@eugeneo
Copy link
Contributor

eugeneo commented Oct 11, 2016

Looks like this has something to do with Chrome itself - there is no reason for it to try and use SSL for devtools connection.

Canary working might be due to the fact of some fixes on Chrome site or a result of different Chrome profile.
Do you think there might be some Chrome extension installed or some setting enabled that forces SSL?

Note that there is a chance the problem will "fix itself" when Node switches to latest protocol so Chrome will be able to use the latest devtools.

@JLHwung
Copy link
Contributor Author

JLHwung commented Oct 11, 2016

@eugeneo

there is no reason for it to try and use SSL for devtools connection.

Thank you for explanation on debug protocol. 🙏

Do you think there might be some Chrome extension installed or some setting enabled that forces SSL?

I just try opening the debugger link (both --inspect and --debug-brk) on Chrome with Private Mode (which means no extension by default), still SSL Protocol error.
Chrome Canary with Private Mode works well.

@ghafran
Copy link

ghafran commented Oct 21, 2016

I was able to workaround this issue by using the ip address instead of a dns name.

Instead of :
chrome-devtools://devtools/remote/serve_file/@60cd6e859b9f557d2312f5bf532f6aec5f284980/inspector.html?experiments=true&v8only=true&ws=server.com:4000/4f4a5721-1d81-46e6-9197-12d390aa251e

Use:
chrome-devtools://devtools/remote/serve_file/@60cd6e859b9f557d2312f5bf532f6aec5f284980/inspector.html?experiments=true&v8only=true&ws=192.168.99.100:4000/4f4a5721-1d81-46e6-9197-12d390aa251e

@JLHwung
Copy link
Contributor Author

JLHwung commented Oct 21, 2016

@ghafran Great appreciation on the workaround. I succeed after replacing localhost by 127.0.0.1, while [::1] does not work.

@JLHwung
Copy link
Contributor Author

JLHwung commented Oct 21, 2016

Inspired by @ghafran, I think this issue is likely of HSTS configuration. It should have nothing to do with v8-inspector and Chrome.

For those who have the same issues, please check the following settings

  1. go to chrome://net-internals/#hsts
  2. On Query Domain panel, input localhost and click Query
  3. If there is any result, go to Delete Domain panel, input localhost and click Delete.
  4. Now check if v8-inspector works or not.

Final Solution:

For devs who does not deliberately add localhost to HSTS settings, please check if there is any HSTS header configuration on your local dev websites. You have to remove HSTS header configuration on localhost or you will be rendered into the same situation after you visit your localhost website.

HSTS settings explains that it works after Chrome setting reset, but the same issue occurs after couple of hours after you visited your localhost dev website, because Chrome will add localhost to HSTS and use SSL on websocket to localhost:9229

I think it can be safely closed after folks confirmed this solution works.

@Trott
Copy link
Member

Trott commented Jul 15, 2017

This issue has been inactive for sufficiently long that it seems like perhaps it should be closed. Feel free to re-open (or leave a comment requesting that it be re-opened) if you disagree. I'm just tidying up and not acting on a super-strong opinion or anything like that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
inspector Issues and PRs related to the V8 inspector protocol
Projects
None yet
Development

No branches or pull requests

10 participants