Skip to content
New issue

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

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

Already on GitHub? # to your account

LiveReload not loading #134

Closed
jacwright opened this issue Jan 30, 2016 · 22 comments
Closed

LiveReload not loading #134

jacwright opened this issue Jan 30, 2016 · 22 comments

Comments

@jacwright
Copy link

I am loading my page from localhost. The livereload script injected into index.html has http://10.201.45.95:35729/livereload.js?snipver=1 which is not my computer's IP (it is 10.0.1.5). But since I don't have port-forwarding on my router to my laptop it can't load the reload script. When I hit the script at http://localhost:35729/livereload.js?snipver=1 or http://10.0.1.5:35729/livereload.js?snipver=1 it loads just fine.

Any ideas where that IP is coming from and what do do about fixing it?

@jacwright
Copy link
Author

If I load http://10.0.1.5:8080/ then livereload uses http://10.0.1.5:35729/livereload.js?snipver=1. But when using localhost it gives the bad URL. This is still the case when I use --host=locahost.

@mattdesl
Copy link
Owner

mattdesl commented Feb 1, 2016

Budo uses the internal-ip module to determine your IP. Can you test that CLI to see if it produces the same problem?

Just so I understand the problem correctly:

  • When you use budo index.js --live without any other options, it produces an invalid IP and doesn't live reload
  • When you use budo index.js --live --host=10.0.1.5 it works fine

@jacwright
Copy link
Author

Correction, when I use budo index.js --live without any other options it starts a server correctly on 10.0.1.5. I can view the page from localhost, but it produces in invalid IP for the livereload.js script that is injected. If I view the page from 10.0.1.5 (without restarting the server) the URL for the livereload.js script is correctly loaded from 10.0.1.5.

When I set the host explicitly to --host=localhost it starts the server correctly on localhost and I have the same behavior as described above.

@jacwright
Copy link
Author

This is no longer happening this morning to me. I'm not sure if there is some strange network configuration things going on. I'm on the same standard home-office network with Comcast.

Still, I see that when setting --host=localhost the server starts up on localhost but the livereload.js script is being injected with the 10.0.1.5 ip. If you fix the injection to use whatever host the server is using it will fix this other intermittent bug.

@mattdesl
Copy link
Owner

mattdesl commented Feb 1, 2016

The reason the injected script uses a specific IP is so that mobile LiveReload can work out of the box. Other suggestions?

@jacwright
Copy link
Author

I have no suggestions. I'm not sure how mobile testing works nor why I was getting that strange IP address.

@mattdesl
Copy link
Owner

mattdesl commented Feb 1, 2016

Ok, there may be some strangeness in the way that budo tries to use default host address that I can clean up and lead to overall less confusion. I will leave this open while I brew on it... 😄

@jacwright
Copy link
Author

Thank you. And good luck! :)

@jacwright
Copy link
Author

Update: it may have been the IP of my VPN address. I'm finding this VPN IP is the IP that budo uses often by default. I'm setting to localhost because I can't have it keep changing (I use localStorage etc. which are keyed to domain) so I'll just go without live reload for now.

Could the server bind to all available IPs? I noticed that http-server will do this (this would solve the problem I believe).

Output of http-server on my machine this morning.

Starting up http-server, serving public/
Available on:
  http:127.0.0.1:8080
  http:10.0.1.5:8080
  http:10.201.45.153:8080

@jacwright
Copy link
Author

I cloned budo and set tinylr to listen on undefined as its host. This way it will bind to any IP. This worked out great. Not sure if this will break anything and why you're limiting budo to a given host in the first place. Why not leave the host undefined for connecting on any IP? For budo and tinylr.

@mattdesl
Copy link
Owner

mattdesl commented Feb 2, 2016

Cool! Right now the reasons I'm using internal-ip is:

  • So it shows in terminal so the user knows which URL to hit
    • http://localhost:9966/ will still work, but it's nice to know the internal IP so you can hit that on mobile
  • So that LiveReload works on mobile too; since setting it to 127.0.0.1 or localhost won't allow LiveReload script to reload across many devices

But maybe we can bind the server to undefined by default, but use the internal IP for mobile LiveReload + logging. I'm not sure that will work with your setup, though.

@jacwright
Copy link
Author

That would be perfect. Use internal-ip for terminal logging, to open up the browser at the right URL (when using --open), and for the livereload.js script. But when binding using undefined.

That sounds like it would work. Incoming PR.

@unframework
Copy link

I can confirm a similar bug report: accessing on localhost:9966 tried to load LiveReload script from a strange IP that was not in my ipconfig or anything. I recently had logged onto a new Wi-Fi network, for context.

Now, similar to the description above, accessing on 127.0.0.1:9966 made LiveReload script tag use the proper IP address. And when I went back to localhost after this, it started working fine too. I think there is some kind of a cache that stores the IP where LiveReload thinks the script lives, and this clears it? It works now, but was definitely baffling for a bit.

Cheers! (And keep up the great work overall)

@mattdesl
Copy link
Owner

For what it's worth, the LiveReload refactor branch mentioned here should not have this issue. Feel free to give it a whirl and see if that version works out OK for you.

@unframework
Copy link

I actually wonder if it has to do with simple browser caching of the index.html content... Doing a hard reload may have helped this issue "fix itself"... Not sure.

@mattdesl
Copy link
Owner

I've definitely noticed a couple quirks in situations like airport wifi and mobile. The new LiveReload backend will probably resolve all that.

@abradley2
Copy link

Having this issue as well- livereload won't work when connected to a VPN

@mattdesl
Copy link
Owner

Thanks for testing @abradley2 – can you try the new backend and let me know?

npm i mattdesl/budo#feature/livereload-rework -g

@abradley2
Copy link

Thanks! Just tried that, I got the following warning:

Bundled LiveReload client could not be found, falling back to bundle the client on demand. This may be because you are using a git cloned version of budo instead of one installed via npm.

@mattdesl
Copy link
Owner

That's ok, the error will go away when it's published on npm properly. What version of node/npm are you on, by the way?

Otherwise, is that new version of budo working with your VPN?

@abradley2
Copy link

yeahp, it's working :)

@mattdesl
Copy link
Owner

Ok, should be all good in budo@10.x now that it pulls in the new LiveReload stuff. Thanks!

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants