Open mortenpi opened 1 year ago
I had a quick look at this but it's not entirely trivial (it doesn't help that I haven't looked at the code that is responsible for this in quite a while).
this bit:
removes a deleted file from the file watcher, this should be the expected behaviour, however this also seems to trigger a refresh which then points to a non-existing page giving a 404, which then doesn't get refreshed when the page re-appears. Your analysis is correct and I understand what you're suggesting. (1) might actually be a bit impractical and may even lead to some confusion, maybe something like it could be done but with an injected banner indicating that the page currently doesn't exist anymore. (2) is definitely a good idea but I need to dig a bit to figure out how that would work.
For (2) I think that what happens is that when a 404 is displayed, the watched file corresponding to the tab (which will trigger refreshes) is the 404 page (or a 404 template), whereas it should be both that page and the file if it exists with preference for the latter (writing this actually just made me think of a way to do this)
I'll try a bit more and might get you to test/review if I get something working. Thanks in any case for the report!
fw
indicating the path that was attemptedWS_VIEWERS
should be able to track both 404 and path as opposed to just one + should fix the fact that it doesn't seem to track even just 404@mortenpi could I get you to try branch tl/i160
please? I think it does what you expected. This led me to fixing a bunch of things around 404s so it's a good thing overall. I still need to fix a few tests also.
So I did a little bit of testing with the latest LiveServer 1.1.2, and one pathological case that I was able to trigger is when you refresh the page. Here I'm just building Documenter's docs and you can see that at first it works fine, but after I refresh the page, it starts auto-refresing to the 404:
https://github.com/tlienart/LiveServer.jl/assets/147757/4a742ad6-e85f-428b-b3e1-dccfc660ec93
Nice thanks for this, can you just give me time pointers of when you hit refresh in the browser (if you do)? and maybe bracket to one event where it doesn't do what you expect? (I see the 404 appearing though, and maybe that's just what you're highlighting here i.e.: that if the behaviour was consistent, it would show the "old" content rather than a 404 so that, in a sense, it's doing one refresh which shows the 404 when it shouldn't, is that correct?)
Also I see how you're running stuff so if you point me to a repo that can reproduce this, I'll try to do the same sequence of include("docs/make.jl")
, tweak a few things etc. One thing I need to investigate is what happens in the watchedfiles dictionary, how it changes during the call etc.
The refreshes (I click multiple times) happen around 1:13-15. You can see the mouse pointer flashing and some activity on the right. Later I don't think I refresh (except to get off the 404 pages), but then when I rebuild, it auto-refreshes to the 404 page. It should indeed keep showing the old content.
For repro, I'd say just build Documenter's manual:
git clone git@github.com:JuliaDocs/Documenter.jl.git
cd Documenter.jl/
julia docs/instantiate.jl
julia --project=docs/
julia> include("docs/make.jl")
And LiveServer.serve
the root of the repo in a different Julia process while re-running include("docs/make.jl")
.
So, I am using vanilla
serve
and notservedocs
, and I build the docs in a separate process. During that build, Documenter temporarily wipes the.html
files, but it takes a short while for the new.html
files to get rendered.As far as I can tell, when the old HTML files get deleted, LiveServer tries to auto-refresh the page, and will then show me a 404. That 404, however, does not seem to auto-refresh when the new HTML files are generated. I basically "get stuck" on the 404 page, even after the HTML file has been re-generated, and have to F5 the page when I switch to that tab.
Unless I have missed something, I can think of two ways this could be handled:
Or, potentially, even both :slightly_smiling_face: