You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
first of all: many thanks for your work, fast-live-reload is awesome.
Setup
I run fast-live-reload in a Docker container so that I request the pages not from localhost but from 192.168.99.100.
I run flr using flr -sp 8000 -s build grunt/livereload in the Docker container
so that content from the build directory is served and flr watches for changes in another directory.
Bug description
Everything works correctly when run locally on the system (not within a Docker container), so the bug is related to a different host string than localhost.
The (potential) bug is in the UpdateNotifier class around line 31. The hostString is correctly determined from the request (from document.location.href) to be 192.168.99.100 but never used afterwards. This results in the WebSocket to be opened (wrongly) to the default host localhost:9001 instead of the correct 192.168.99.100:9001. When I hard-code the correct host string in line 41 after all the automatic determination, everything works as expected.
Solution
I did not directly fix this in code because I am not sure how exactly the different ways of specifying the fastLiveReloadHost value should be prioritized. But I am pretty sure that without giving any additional parameter (e.g., you describe the way via GET parameters in the docs), the already correctly determined hostString should be used somehow.
The text was updated successfully, but these errors were encountered:
Hi,
first of all: many thanks for your work, fast-live-reload is awesome.
Setup
I run fast-live-reload in a Docker container so that I request the pages not from
localhost
but from192.168.99.100
.I run flr using
flr -sp 8000 -s build grunt/livereload
in the Docker containerso that content from the build directory is served and flr watches for changes in another directory.
Bug description
Everything works correctly when run locally on the system (not within a Docker container), so the bug is related to a different host string than
localhost
.The (potential) bug is in the UpdateNotifier class around line 31. The hostString is correctly determined from the request (from
document.location.href
) to be192.168.99.100
but never used afterwards. This results in the WebSocket to be opened (wrongly) to the default hostlocalhost:9001
instead of the correct192.168.99.100:9001
. When I hard-code the correct host string in line 41 after all the automatic determination, everything works as expected.Solution
I did not directly fix this in code because I am not sure how exactly the different ways of specifying the fastLiveReloadHost value should be prioritized. But I am pretty sure that without giving any additional parameter (e.g., you describe the way via GET parameters in the docs), the already correctly determined
hostString
should be used somehow.The text was updated successfully, but these errors were encountered: