chrome - use tab's current host rather than 127.0.0.1 #16
Conversation
|
Please merge this and re-publish to chrome store. This plugin is awesome, but completely useless if your development box is not localhost. |
|
Seems like there's no support from the author ;/ Shall we publish it on Chrome Apps ourselves? The lack of this option kills me in almost every project I work on. The source seems to be MIT licensed . |
|
It seems that @bigwave has the most uptodated version. However the firefox extension seems to have the similar bug.. |
|
I've published this to the Chrome App Store, but you need the URL to install it. https://chrome.google.com/webstore/detail/remotelivereload/jlppknnillhjgiengoigajegdpieppei It's only available if you know the URL because this is my first published extension, and it's still a bit rough. No description, screenshots, etc. etc. Feedback appreciated. |
|
Could you try this and see if it works? https://addons.mozilla.org/en-US/firefox/addon/remotelivereload/ |
|
Ohh.. I have missed your comment somehow. Yes, now it works as expected. I have also forked the repo and replaced extension's building system to Grunt. Now it builds with Would you like to merge this to your fork? Should I PR to you? |
|
Yes please, I only learnt rake for this project, so I'm happy to have something JavaScript based |
|
Ok. So I think you should |
|
Merged, version incremented and re-published for Chrome and Firefox (just to make sure the new build process works for deploys to apps stores) |
|
Thanks for this guys! It's a shame this pull hasn't been accepted yet... |
|
Hey! Sorry guys for neglecting this for so long; I'm back to active maintenance. That said, I'm afraid I don't agree with this feature as is. A valid use case for LiveReload is to run it on a live web site (say http://livereload.com) with a local server serving CSS overrides. What's your use case for it? Running grunt-watch on a remote system? |
|
@kolya-ay @bigwave @jtomaszewski If you guys are interested, I can give commit access to the main repo to anyone who wants to contribute in general. Regarding this particular change, I'd love to resolve it without introducing options or other complications like that. How about trying localhost first, and then, if it doesn't respond, trying the page's origin domain? |
|
@andreyvit in our case the |
|
@andreyvit My personal use case is playing about with web sites on a raspberry pi to control servos, LEDs, cameras, etc. And I don't want to run a "non-standard" browser on low power hardware, so I use ssh and browsers on my laptop. Probably not the most common use case I will admit. |
|
@andreyvit, my use case is opposite to @js-'s. I run
The solution looks reasonable: localhost first because of virtual opportunity to have two (local & origin) livereload servers started. However it's still hard to imagine who wants to modify locally the beautiful http://livereload.com CSS;) Regarding the project future, could you take a look on commits I have made a year ago. Besides relayout the fork contains some useful grunt automation (version inferring, crx building). Would you consider a PR from me? |
|
@kolya-ay I've already did some relayout (including a switch to Grunt for builds), check it out. I'll happily merge most of pull requests, unless I particularly disagree with something. You have a lot of useful changes in there, like a keys directory. I'm not sure I want to switch all extensions to a template copying approach; I thought about it, but at least the Safari extension's manifest needs to be edited in Safari GUI, so a separate copy would be harder to maintain. I've kept version stuff in Rake for now, because I hate editing Gruntfiles (can't wait till I build some GUI for that, been on my mind forever), but I'm open to switching to Grunt for that as well. |
|
Ok, it's matter of taste;) Should I make a PR to include origin listening? By the way, I'm not sure, but it seems that building the Safari extension could be automated too. |
|
@kolya-ay Well I can do it myself, but if you have time next week or two, you'll beat me to it. Given that the script reconnects on each reload, I think it's best to start connecting to both endpoints at the same time. And if both succeed... well why not stay connected to both? But if that's too much work, I guess we can just pick the first one to connect. |
|
@andreyvit can you please merge it? |
|
@andreyvit the use case here is having a docker instance for developing, so it's really useful. Please merge it |
|
@camilonova, @ikks I understand the use case, but this change breaks the normal usage with my app, so it cannot possibly be merged as is. |
|
@andreyvit you already have a workaround at http://feedback.livereload.com/knowledgebase/articles/86180-how-do-i-add-the-script-tag-manually Seems it will keep the normal use of the app, but it will not work for anyone running the dev server different than localhost. Why do you think it break your normal usage? |
|
@andreyvit could you at least merge #35 which seems to change a lot less than this one? |
|
chime in What about the idea of trying 127.0.0.1 first (for BC) and then resorting to the tab's host? For me, everything (including the watch & livereload) runs inside a Vagrant virtual machine, so 127.0.0.1 does not work. |
I have just upload a custom version that allow set your custom host and port: |
|
It would be nice if this could be fixed for us that have VMs as dev-machines. |
Here the link where you can define the host: https://github.com/lokcito/livereload-extensions |
fixes #15