mattdesl / budo

:clapper: a dev server for rapid prototyping
MIT License
2.18k stars 106 forks source link

LiveReload not loading #134

Closed jacwright closed 7 years ago

jacwright commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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:

jacwright commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

jacwright commented 8 years ago

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

mattdesl commented 8 years ago

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... :smile:

jacwright commented 8 years ago

Thank you. And good luck! :)

jacwright commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

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 commented 8 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

abradley2 commented 7 years ago

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

mattdesl commented 7 years ago

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

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

abradley2 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

yeahp, it's working :)

mattdesl commented 7 years ago

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