This is highly reproducible, and discussed previously in BrowserIssues. This is an IE5/IE6-specific problem whereby going back from Preview sometimes doesn't work (typically because you clicked on a popup window link in the Preview window, e.g. TextFormattingRules). This is because IE5/6 seems to always flush the cache when you open a popup window (or perhaps any new window), causing the Back from preview to re-fetch the old page. This doesn't happen in other browsers (unless they are mis-configured without cache or to always check the server for updates).

It occurs on various TWiki sites, including twiki.org and intranet TWiki installations.

This is quite annoying, particularly for novice users of TWiki, who could lose quite a lot of text without any warning at all. In fact, novices are most likely to have this problem since they consult the help windows...

Workaround

Immediate Workaround: if you notice this in time, hit the Forward button, then press Preview button again, then Save, then Edit.

Fix record

This is of course a browser problem, not a TWiki bug - however, since IE5 is so common, is in many other ways a good browser for TWiki usage, and this bug involves the loss of work, there is now a fix.

I've committed a fix for this bug, and the required RefreshEditPage fix, to CVS for TWikiAlphaRelease - affects view, edit, and Twiki.pm. Cache control HTTP headers are only generated for the Edit page, never for any other pages, so it won't affect the timeliness of View pages.

The fix has been tested on IE5.5, Opera 5.12 and Mozilla 0.9.9, and is based on code I've had running locally for two months without problems. The fix does not work for some IE6 users - check BackFromPreviewStillLosesText for latest status.

UPDATE: I've noticed that the CGI.pm module generates some HTTP headers in lower case - although this looks a bit odd, the HTTP/1.1 spec says this is OK, so it's not really an issue.

However, the Last-Modified headers work fine for IE5/IE6 as far as I've tested, i.e. they fix this bug - can you post the details of the browser you are using, and the test case you used to show they are being ignored or causing some other problem?

I remarqued this under mozilla: on "View/Page info" it said that the last-modified
field was not set. By using the wget web batch downloader in verbose mode, it said
"Invalid last-modified date - ignored".

I would guess that IE, too is ignoring it, but that it doesnt show as the last-modified date
is not relevant for our uses. But it should be fixed...

Thanks for the report. The change of 20 April has not gone into TWiki.org yet, btw.

Please open a new bug report via BugReports, with all the details - exact IE6 version, OS version, is this reproducible, are you using any web proxies, etc? Details of how to reproduce the bug are important, of course. Unfortunately, I don't have IE6 and can't install it locally because it breaks some intranet apps.

Also, if you have wget or some other way to view headers (e.g. the JunkBuster proxy with debug 1, 2 and 8 turned on), it would be very useful to do an Edit on TWiki and view the headers. If the results include the cache-control headers below, the fix is working OK and there is an IE6 issue that is a bit more subtle than we thought. If not, some proxy (perhaps a SourceForge cache, though that's unlikely) may be interfering.

This also works OK with IE 5.5 on Win2000. However, I don't know if anyone has tested the fix on IE6 yet. Since the fix went in on TWiki.org, the occasional loss-of text problems have gone away, at least for me, so I suspect this is IE6 specific.

I think this can be set to 100% implementation, since anything else is really a new bug - the docs are already in BrowserIssues, so we just need to move that topic into the TWiki web and integrate it into the docs, with a bit of editing.

The only true fix for this bug is to stop relying on the browser cache behavior. Cache control headers are hints, they do not dictate what the browser will do. The browser may not cache your page because it has no more memory, or it has more important pages, or maybe because it just dosn't like you. This is completely acceptable behavior for a browser.

Since the current "back" behavior has several useful properties, such as restoring the scroll position of textarea elements, it is likely that this will simply remain unfixed since it works well "most of the time". If you experience this problem in IE as a user, you can try some of the IeNoCacheWorkarounds.

See my comments on BackFromPreviewStillLosesText - a skin/template change for Re-Edit would be a better approach really, but people will always hit the Back button, making this fix quite important even with new skins/templates. Performance of hitting the Back button will always be pretty good, particularly on a very slow TWiki server (which has happened sometimes at TWiki.org due to SourceForge slowdowns) - it would have been really painful to re-submit edit pages if back from Preview had not been working during these slowdowns (which caused server errors on many pages).