Thomas Dickey wrote: >This report doesn't indicate a version where Lynx behaves as you expect.
Strangely, this misbehaviour doesn't seem to have arrived with a specific Lynx version, but developed over time. I'm sure that the present version worked fine on these websites when it was first installed here a year and a half ago. It was definitely working for <https://www.theguardian.com> two weeks ago, for which it's not working now. Presumably this version always had the bug, but it's being triggered by some unusual environmental condition that has changed over time. So I never noticed this bug with the previously-installed Lynx version, whatever that was, but I don't see any reason to think that that version actually lacked the bug. If you can't reproduce the problem, I could have a go at compiling a bunch of Lynx versions from source to see which ones do this. >This sounds like the longstanding Lynx behavior: it doesn't automatically >reload a page which has been read and is cached locally. I'm not sure quite what behaviour you mean there. Maybe I've failed to explain the bug clearly enough. The bug I'm reporting is not mere caching behaviour: it's not a cache operating correctly, nor is it merely a matter of a cache serving up stale information. In the past I have observed that, when invoking loading of a recently-loaded page (as is the situation in the bug report), Lynx will show the requested page from cache. That is, it shows the page instantly rather than making a network request for it, and if the page is volatile then the version that it shows may be the previously-loaded version rather than current. This behaviour is totally fine, and is not what the bug report is about. (Incidentally, trying it now, I'm seeing this caching behaviour from "u" commands popping the history stack, but not from repeated selection of ordinary links. Don't know whether this is normal or not.) In the situation of the bug report, other than it being specific to some websites, the condition for the bug to manifest does look a lot like the condition for Lynx to serve a page from the cache. But the behaviour is not to serve the page from cache: the requested page does not get shown at all. No history entry gets pushed, and Lynx continues to display the page from which the link was selected. The user can continue navigating in the displayed page, as if ey had never selected the link to the other page, or as if loading had failed due to a network problem (though no error message is displayed). This is not long-standing behaviour in my experience: it is new and problematic. -zefram
