Debugging: Dev Tools launch to 10.0.2.2 instead of localhost

[foggy1]

Is this a bug report?

Yes

Have you read the Contributing Guidelines?

yes

Environment

Environment:
OS: macOS High Sierra 10.13.3
Node: 8.7.0
Yarn: 1.3.2
npm: 5.6.0
Watchman: 4.7.0
Xcode: Xcode 9.2 Build version 9C40b
Android Studio: 2.3 AI-162.4069837

Packages: (wanted => installed)
react: 16.2.0 => 16.2.0
react-native: 0.53.0 => 0.53.0

Steps to Reproduce

1. Run app on Android.
2. Turn on Debug mode.
3. Bundler says "Launching Dev Tools..." and it opens chrome to http://10.0.2.2:8081/debugger-ui, which hangs because the debugger is on localhost.

Expected Behavior

I expect the debugger to open Chrome to localhost:8081/debugger-ui as it always has before I upgraded to version 0.53.0.

Actual Behavior

As mentioned, it opens to http://10.0.2.2:8081/debugger-ui, which is inoperable. Nothing ever loads. The Devtools middleware has the wrong host for some reason.

Reproducible Demo

You can literally react-native init a new app right now, and it will do this. Here's a package json of an app I just generated that has this issue

{
  "name": "testingtesting",
  "version": "0.0.1",
  "private": true,
  "scripts": {
    "start": "node node_modules/react-native/local-cli/cli.js start",
    "test": "jest"
  },
  "dependencies": {
    "react": "16.2.0",
    "react-native": "0.53.0"
  },
  "devDependencies": {
    "babel-jest": "22.2.2",
    "babel-preset-react-native": "4.0.0",
    "jest": "22.3.0",
    "react-test-renderer": "16.2.0"
  },
  "jest": {
    "preset": "react-native"
  }
}

It appears the app bundle is also being loaded from 10.0.2.2, but the debugger is not functioning at this host, which I'm guessing means that even if I navigate to a "working" debugger @ localhost, it's still not going to work. Credit to #17910 for first assuring me I was not crazy and this was a real issue.

Edit: Complete shot in the dark here, but could it have something to do with fa574c6 ? (happy to pr this with some direction, although I know at least part of the issue is in a separate file where it is also incorrect about the host when launching chrome).

[hramos]

(The bot might mark this as no-template, but it's because this issue is missing the first line from the template. Disregard)

[foggy1]

@hramos (edited to add it in)

[hramos]

Reopened, sorry about that. The bot is pretty naive when it comes to checking the template is followed, but it manages to catch the issues we really want to close immediately (where the whole template is deleted).

[inform880]

I'm getting this too on Windows. Really annoying.

Environment:
OS: Windows 10
Node: 6.11.1
Yarn: 1.3.2
npm: 5.6.0
Android Studio: 2.3 AI-162.4069837

[amcsi]

I'm getting this issue too on my new react-native project, although even manually going to http://localhost:8081/debugger-ui/ doesn't work.
I could swear this was working fine several weeks ago on a different react-native project.

Environment:
OS: Windows 10
Node: v9.4.0
npm: 5.6.0
Android Studio: 3.0.1

react-native-cli: 2.0.1
react-native: 0.53.0

[amcsi]

I can confirm that on my older react-native version 0.52.2 project work perfectly fine in terms of remote debugging.

The new 0.53.0 might be the cause of this issue.

[perseyMudzinga]

Go to http://localhost:8081/debugger-ui/ . Then stop remote js debugging and run your react native app again. Finally debug js remotely. Has worked for me.

[foggy1]

@perseyMudzinga Ok, that's good to know for when I need it. I was worried it wouldn't connect at all anymore.

Still, I'm wondering why the function that launches chrome in the middleware is wrong about the host (it thinks the host is, I believe, the location where the Android emulator runs, rather than localhost).

[hramos]

The original post refers to fa574c6 as a possible cause. Commenting here to point to #15547 which is the PR that introduced that commit.

[rgoldiez]

Running into this as well. I only started running into this on 0.53.x. Didn't have this problem on 0.50.x. I grepped through node_modules/react-native and notice a few places where 10.0.2.2 is hard coded. I'm not using remote js debugging.... I'm just trying to run from Android Studio.

[Bosseskompis]

I also have this issue on 0.53.x, but not any version prior.

[vinipachecov]

@perseyMudzinga Your solution works for me. I've checked react-native modules and @rgoldiez is correct, AndroidIfoHelpers.java has the hard coded 10.0.2.2 for emulator localhost:

[peacechen]

It would really help development to change the hardcoded 10.0.x.x IPs to localhost. Any chance this fix could be released as 0.53.4 ? If not, when is 0.54 going to be final, and will this fix be incorporated?

[arapocket]

This is extremely annoying and shouldn't be an issue.

[boliveira]

How is this such BASIC problem not yet fixed?

[symptomatik]

I also have this problem and the workaround from @perseyMudzinga worked for me. Thanks!

[peacechen]

"How is this such BASIC problem not yet fixed?"

Apparently debugging isn't a priority for FB 😜

[esprehn]

For us with JS Deltas disabled and manually opening a tab to localhost:8081 and refreshing again the debugger works. It seems like there's a bug where the emulator is opening a chrome tab against EMULATOR_LOCALHOST but should be opening it against DEVICE_LOCALHOST?

[xgenvn]

Confirm the same issue on Ubuntu. Hope this will be fixed soon. It's worse if someone is using standalone react-native debugger. I'm investigating how to change the URL, though.

[fungilation]

Ya this is stupidly tedious even for those like me who does know about this issue, and every time having to change chrome's debugger url from 10.0.2.2 to localhost.

And this is only on Android. On iOS, I changed my AppDelegate.m with this line:

jsCodeLocation = [NSURL URLWithString:@"http://192.168.1.100:8081/index.bundle?platform=ios&dev=true"];

With 192.168.1.100 my mac's LAN ip. It can be localhost or any ip I want it to be. Is there no similar config option for Android, and shouldn't there be?

[fungilation]

For android emulator, CMD+m > Debug server host & port for device and changing it to localhost does not change the chrome devtools url launch behavior for me. It still always open with 10.0.2.2.

[rajashekarmakam]

For android emulator, CMD+m > Debug server host & port for device and changing it to localhost does not change the chrome devtools url launch behavior for me. It still always open with 10.0.2.2.

I also face the same problem.

[VictorQueiroz]

How such basic things like this can be a problem for RN developers? That's just sad.

[elicwhite]

It seems like for some people localhost:8081 is the right URL and for others 10.0.2.2:8081 is the correct url. I believe at one point the default was changed from 10.0.2.2 to localhost because of a similar thread to this one complaining about the other direction. Simply flipping the default back is not sufficient to really solve this problem. It seems like different people have different set-ups and figuring out how to support both is critical to resolving this.

I haven't investigated the changes necessary to make this change, but it would be interesting to change the logic to try localhost, if that fails, try 10.0.2.2. If one works, cache the result until it doesn't resolve anymore at which point the system tries to resolve the correct endpoint again.

If someone was interested in investigating where this kind of change would need to be made and how such a change could be verified, I think we would be very interested in such a solution.

[fungilation]

Nowadays, I don't see there's much case left for 10.0.2.2. I've went from Mac to Windows dev, and for both iOS and Android (emulators). localhost works in all cases, 10.0.2.2 doesn't. And for Android, I've used both genymotion and standard android emulator.

[fogil]

Have RN read from an env variable like RN_DEBUGGER_URL, instead of using that garbage hard-coded string that only works for 50% of people.

Problem solved. Thank me later.

[fungilation]

And/or config variable in package.json

[stepanhruda]

I'm having a hard time figuring out the use case where you'd want to open a Chrome window pointing at 10.0.2.2. That's an address visible from inside the emulator - it's relevant for e.g. packager purposes inside the VM, but never relevant to applications outside of the VM (Chrome).

If there's no good use case, I'll switch this option to always open pointed at localhost.

[fungilation]

I have zero use case for 10.0.2.2.

But by making the debugger URL easily configurable, I would switch it from localhost to a internal LAN ip like 192.168.1.xxx for on-device debugging. Versus now where I'd have to hardcode the change in native code. 2 birds with 1 stone?

[hengkx]

There are still problems.

[Ndukuzempi]

I solved the issue by:

• Press Cmd + M on emulator screen
• Go to Dev settings > Debug server host & port for device
• Set localhost:8081
• Rerun the android app: react-native run-android

Debugger is connected now!

Solution works fine for me, however had to change from localhost to my machine IP address. e.g. 10.1.1.1:8081

[MSSPL-PiyaleeMaiti]

@Ndukuzempi I try this slution before it's not working.
Admin should find permanent solution for this, otherwise it's so difficult for developer to debug their project.

[traviisd]

I got this to work by following a combination of above comments. Maybe this will help someone.

react-native 0.57.4
react-native-cli 2.0.1

• Ensure adb is in PATH
• Start Android emulator
• Run react-native run-android
• Open http://localhost:8081/debugger-ui/
• cmd + m on emulator screen
• Select "Enable Remote JS Debugging"
• Select "Enable Hot Reloading"
• Select "Reload"

[Hyllesen]

Soon one year later and I'm still having this issue on Windows. It's a really basic thing so I'm amazed it hasn't been fixed.

[kelset]

I honestly can't tell if the comment above is just trolling.

But ofc I've screenshotted it, deleted it and reported this person as it ofc violates all the kinds of CoC I can think of.

Let me be extremely clear: as someone who doesn't work for Facebook and help with React Native without getting any kind of payment, seeing comments like those is embarassing. The community we have been trying to cultivate can and should be better than that.

[VictorQueiroz]

you deleted my post suggesting this library is being censored? Are you serious kelset? I'm linking everyone to this thread.

@clevertree Which comment? What did you say?

[clevertree]

Thank you for your reply Victor, I don't have a copy of it. Only Kelset does.

Here's what I suggested, which will apparently get me banned?!?#

Facebook might be depreciating these libraries on purpose by encouraging it's remaining supporters to

1. Not fix long term bugs
2. Cause unnecessary library conflicts
3. Hardcode values to favor one OS over another

I could go on and on. I believe I have the right to suggest this without being banned, right?

[VictorQueiroz]

@clevertree I think it might be perfectly possible. Either way it is very sad that a library used and starred by so many have such a poor environment for the developer. Turns out that for me it seems so much easier to just develop for Android using the available tools and go native whenever it is needed. Unfortunately, at the end of the day, going native is the best way of developing reliable applications.

[fungilation]

Your conspiracy theories make 0 sense. You seem to know nothing about how OSS works nor how Facebook's business works. Either contribute here or get out, simple.

That said, 10.0.2.2 by default is a longstanding stupidity that should be rectified to localhost. It's more politics and perception that's stopping this, so how about this:

Those who favor and have sound reasoning for staying with 10.0.2.2 by default for android debugger, speak now or forever hold your piece.

[cpojer]

Thanks everyone for participating in this discussion. As @TheSavior pointed out, it seems depending on environment setup, the debugger should be using different addresses. However in this issue we have not made any progress in trying to understand what the actual root cause for the difference is, which makes it hard to figure out the right fix.

The good news is though that we have just extracted the cli/debugger related code into a new repository that is entirely managed by the open source community since we are not using this code at Facebook. I'll close this issue here and will let somebody from this thread create a new issue in the react-native-cli repo. I encourage you to try to understand the cause for the differences, and then submitting a PR to that repo with a fix that will work for all users, rather than one subset or the other.

The discussion here has been quite heated and unproductive in finding a resolution so I'll lock this issue.