Earlier Discussion on BackFromPreviewStillLosesText

Follow up

TWiki.org does have the fix applied, btw, the headers show this. Not sure why there is a 4 second difference, but it may be that the CGI.pm code uses a different date (maybe launch time of script) to generate this. I don't think this causes problems, though it looks odd.

Is this consistently reproducible? It sounds like it is, from your steps to reproduce.

The original issue only happened if you edited a page, then opened a new browser window (e.g. the GoodStyle popup on edit page), hit Preview and then hit back button. If this is happening without this sequence of events, it is a different bug IMO, though probably related.

Can you also post:

• Your IE6 cache settings
• Whether you are using any proxies - and results of tests with the proxy bypassed
• Whether this happens on a local TWiki (this is because SourceForge apparently has some sort of server-side proxy)

Not sure what the attachment is for - the fix code is not involved in attachment downloads of course.

Thanks.

-- RichardDonkin - 23 Apr 2002

Not using any sort of proxy.

IE cache settings are to check for "newer versions of stored pages": automatically (alternatives are: per session, per access, never).

This does happen on a local TWiki (20020414 beta)

In fact, this happens all over the darned place, far far more then it ever happened on previous versions of IE, in the form of "information for this page has expired - please press the refresh button" - and when you do that, it pops up an annoying msg. box blathering about resending information - once you click "ok" on that, it retrieves the page. With TWiki it doesn't do any of this, it just loads the editing page with the content just added lost.

-- DavidLeBlanc - 24 Apr 2002

I tried changing IE settings to "per session" and "per access" and it still lost the new edit. I did not restart IE after each change, so that might have a bearing on it.

-- DavidLeBlanc - 24 Apr 2002

I suspect that the IE settings to check for "newer versions of stored pages" are the problem - this should be 'per session'. The 'newer versions' setting tells it to never use the cache (or at least to do an If-Modified-Since on every page, which on TWiki causes it to always reload the page). This is mentioned on BrowserIssues by the way (now updated to mention this case explicitly).

Then just reboot your system (or maybe just IE) having changed this option (not sure if it notices the settings change on just a browser restart, though it should do.)

-- RichardDonkin - 25 Apr 2002

Setting "per session" (actually "Every time you start Internet Explorer") does not fix the problem. Interestingly though, if you go back (seeing undone edit), then go forward, you get the "page expired - hit refresh" message. Doing that gets the "information must be resent" dialog and then you get a preview with the new edits.

I reviewed the BrowserIssues page, and when I first reported this bug, I had IE 6 set to "automatically".

FWIW, I didn't see this problem with IE 5.0 (on NT), but did start seeing it on IE 5.5

-- DavidLeBlanc - 26 Apr 2002

Try setting the cache to "automatically", then reboot your PC. I have had no problems with IE 5.5 SP2, which I use all the time with "automatically", so I suspect something about your setup is different. I just re-tested with IE5.5 on this page and the fix works OK.

Which OS version are you using? I'm on Windows 2000, and IIRC there are some differences between IE6 on XP and other Windows OS.

Could you also check whether your ISP is using transparent proxy caching? This has a bad effect on some versions of IE (see BrowserAndProxyCacheControl) though I think IE6 has fixed this. The headers do seem OK, but perhaps a transparent proxy cache is interfering. One way to test this is to do telnet twiki.org 80 then GET / and see what headers you get back.

Are there any other IE6 users out there who could also test this? There's a simple test procedure at top of BackFromPreviewLosesText which only takes a minute, and can be used on TWiki.org.

-- RichardDonkin - 26 Apr 2002

Works fine for me - Win2K and IE 6

-- JohnTalintyre - 26 Apr 2002

I just did the test with IE6.0.2600(etc) on Win2K. When I used the browser button to go from the Preview screen back to the editing screen my line of text was still there.

I have my browser set to Check for Newer Versions of Stored Pages "automatically." Sympatico (my ISP) is notorious for caching content, but it doesn't seem to be a problem in this case.

EmmaJane - 27 Apr 2002

I tested this on Windows XP with IE 6.0.2600, and I did seem to get this if I waited 30 mins or so between the Preview page and hitting the Back button. However, this didn't recur when I tested it again, either with the cache settings Automatically or 'Every time I start Internet Explorer'. So this seems to be intermittent.

-- RichardDonkin - 11 May 2002

Sorry, I have been pre-occupied with other things and only just getting back to having some time for Twiki.

My ISP says they don't do caching of any kind. They are "theriver.net", so if anyone happens to know differently, please let me know.

I'm running Win 2k pro sp 1 with IE 6.0.2600.

I'm also running TinyPersonalFirewall and I just checked and disabling it doesn't cure the problem.

-- DavidLeBlanc - 15 May 2002

I just had this problem using IE5.5 SP2 with latest updates, on Win2000 SP2, using TWiki.org - it only happened once, and it's possible I hit the ESC key or something to cause this, since it wasn't reproducible, but it did happen. It is very infrequent though, as I quite often do back-from-preview and open new windows.

If anyone does get this problem, try hitting Ctrl/Z with cursor within the text box - if the ESC key or some equivalent actually caused the loss of text, Ctrl/Z will get it back.

Just noticed DavidLeBlanc's question from a while back:

• Why is the topic title for every page in Codev downloaded for an edit!?! I've attached the text that wget downloaded showing this!
  • You are using the JavascriptBasedEditor, which downloads the topic names for use in the drop-down topic-name box. This is rather inefficient for Codev, which has over 1200 topics, particularly for dialup users. --RD

-- RichardDonkin - 28 May 2002

I had this bug again (first time in many months) on a local TWiki, which includes this patch. I had been using IE a lot with an unsaved Edit window, so it's possible that in some circumstances (e.g. some objects need to be removed from cache) that IE decides to remove the cached Edit state. No great cause for alarm, but worth bearing in mind if you are using IE a lot - just Save your Edit page in case you forget and end up with this problem. The normal 'forward from Edit' workaround saved my edits, fortunately.

Environment: IE5.5 SP2, Win2000 SP2, TWiki May 2001 code (including this patch), no proxy caching.

Like my test on IE6 and Windows XP above, this involved quite a long wait on the Preview page (30 mins for the IE6 test and over an hour for the IE5.5 test) - so this bug may be time-related. If you get this problem, try running a test where you wait at least 30 minutes on the Preview page before hitting Back - and if possible, use IE for other web tasks, including opening new windows, during that time.

-- RichardDonkin - 25 Sep 2002

RandyKramer had this problem on IE 5.5 with various proxy servers and firewalls between browser and TWiki - see his comment of 30 Sep 2002 on ExcludeSearchResultWithRegEx.

-- RichardDonkin - 29 Nov 2002

I am now getting this problem on all topic edits. I think its due to the use of the TigerSkin.. could this be true?

as this is breaking the bug tracking system (all edits are cached, thus loosing important changes) I have set expireSeconds to 0 and added no-cache to the edit.tiger.tmpl

• using Galeon, IE5.5, ie6.0, mozilla, opera

-- SvenDowideit - 19 Mar 2003

The problem of caching all edits is RefreshEditPage - the changes you describe will completely break BackFromPreviewLosesText. I don't think this is a TigerSkin issue, as I haven't heard of this skin in context of this problem.

Please describe exactly what the problem is - it may be that RefreshEditPage is not working. Also, latter bugfix can't handle the case where people use the Back button to visit a previous page - many browsers, e.g. Opera, cache previous pages for use by Back button quite differently from other cache usage. If you need latest state in this case, consider a JavaScript refresh link/button that does javascript:document.location.reload(), e.g. Refresh. You might even be able to make this triggered by the onLoad event, but this might be hard to get right and should be limited to pages that really need it.

UPDATE: The skin may be why RefreshEditPage is not working - check all Edit buttons and links in the skin against the suggested HTML in the RefreshEditPage topic, and against the latest TWiki standard templates. This should remove need for any JavaScript refresh stuff for the normal 'hit edit on page' case.

-- RichardDonkin - 19 Mar 2003

Strangely, I am currently experiencing this problem at TWiki.org. My setup is: IE 6.0.2600.0000.xpclnt_qfe.010827-1803 update versions: q328767; q324929; q810847. Running XP Pro and Zone Alarm Pro 3.7.098 (not that that should make a difference). I am not going through a proxy. I cannot tell when this problem began because I have been inactive at TWiki.org for a while. Regards, Martin.

-- MartinCleaver - 08 Apr 2003

I was also having this problem on the December 2001 release with the patches

The problem was 100% reproducable by doing edit, preview, back (no need to open any other pages like TextFormattingRules)

Running wget showed that the headers were being sent.

I finally tracked this down to our use of SSL.

In IE if you use SSL (https) you need to disable the internet settings / advanced / security / don't store encrypted pages to disk option. (and restart the browser after this).

Otherwise it goes back to TWiki each time and you loose your edits. Other browsers (Netscape, Mozilla, Opera) don't have the problem.

I don't know if there's any way of fixing this from the Wiki side. The only reason we are using SSL is to prevent the password being sent in clear over the network (the content is not confidential but the password is)

-- MartinFuzzey - 11 Apr 2003

Thanks for pointing out the SSL issue, will mention under BrowserIssues - there's no way TWiki can control this from the server, as IE is overriding BrowserAndProxyCacheControl HTTP headers. The annoying part is that there's no reason to cache SSL protected pages on disk just in order to enable the in-memory caching of previous pages (for the Back button to work properly in this case) - however, that's just how InternetExplorer is designed.

-- RichardDonkin - 12 Apr 2003