Bug: Back from Preview loses text

FIX AVAILABLE: See #Fix_record if using older TWiki code - now implemented in TWikiRelease01Feb2003 and on TWiki.org.

Test case

• Edit a test page using IE5.x/6.x (I used IE5.01, IE5.5 SP2 and IE6.0)
• Add one line to the page
• Click the TextFormattingRules link
• Use right-click menu to Refresh the pop-up window, in case it was cached, then close it.
• Hit Preview, then hit the browser's Back button (note slight extra delay on Back)
• The line you added earlier has disappeared.

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...

Other reports: EditChangesLostAfterPreviewOnIE and SaveAndContinueWorkingFromPreview (brief mention)

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.

(Older discussion moved to BackFromPreviewLosesTextOld - not relevant now that fix is in TWikiAlphaRelease.)

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.

-- RichardDonkin - 21 Mar 2002

I think you have a small bug in writeHeaderFull. It seems to write invalid Last-modified headers ("Mar 21 2002" instead of "21 Mar 2002"), which are thus ignored.

Instead of

      -last_modified => $lastModifiedString,

@isoDay = ( "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat" );
   ...
      my( $sec, $min, $hour, $mday, $mon, $year, $wday ) = gmtime();
      $year = $year + 1900;
   ...
      -last_modified => "$isoDay[$wday], $mday $isoMonth[$mon] $year $hour:$min:$sec GMT",

-- ColasNahaboo - 28 Mar 2002

This is against the HTTP Date spec, thanks for pointing this out.

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?

-- RichardDonkin - 28 Mar 2002

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...

-- ColasNahaboo - 28 Mar 2002

Thanks for the bug report and clarification - this is now fixed in CVS for TWikiAlphaRelease, based on the HTTP 1.1 spec (RFC:2616) and the Perl HTTP::Date module.

-- RichardDonkin - 28 Mar 2002

Fix is now implemented on TWiki.org, with RefreshEditPage. This means no more loss of data on editing!

-- RichardDonkin - 05 Apr 2002

Fix updated to implement new plugin API for HTTP headers - see MorePluginHooks for discussion, and CVS:lib/TWiki.pm for the code, in writeHeaderFull.

-- RichardDonkin - 20 Apr 2002

As of 19 April 2002, back button still loses edits on Twiki.org using IE 6.0. I'm putting this back to "active bug" so this comment will be noticed.

-- DavidLeBlanc - 20 Apr 2002

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.

Using wget just now, I got the right headers at least:

$ wget -S --http-user=RichardDonkin --http-passwd=xxxxxx http://twiki.org/cgi-bin/edit/Test/RichardsPage
...
--09:10:21--  http://twiki.org/cgi-bin/edit/Test/RichardsPage
           => `RichardsPage'
Resolving twiki.org... done.
Connecting to twiki.org[216.136.171.204]:80... connected.
HTTP request sent, awaiting response...
 1 HTTP/1.1 200 OK
 2 Date: Sun, 21 Apr 2002 08:10:21 GMT
 3 Server: Apache/1.3.20 (Unix) PHP/4.0.6
 4 Cache-control: max-age=86400
 5 Expires: Mon, 22 Apr 2002 08:10:23 GMT
 6 Last-Modified: Sun, 21 Apr 2002 08:10:23 GMT
 7 Content-length: 72170
 8 Keep-Alive: timeout=15, max=100
 9 Connection: Keep-Alive
10 Content-Type: text/html   

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.

Right now, SourceForge is misbehaving, which together with IntermittentFailures makes me think this might be something to do with this problem.

For followup on this problem, see BackFromPreviewStillLosesText - seems to affect some but not all IE6 users. I've set BackFromPreviewLosesText to BugResolved, since the basic fix is still working for other IE versions.

-- RichardDonkin - 21 Apr 2002

What specifically is still needed to bring this BeijingRelease feature status up from 97% implementation and 50% documentation?

-- GrantBow - 09 Jan 2003

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.

-- RichardDonkin - 09 Jan 2003

Cool. Do you need some help with this?

-- GrantBow - 28 Jan 2003

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.

-- DavidJeske - 07 Jul 2003

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).

-- RichardDonkin - 08 Jul 2003

Removed patches and page from TWikiPatches, since in core TWiki code since Feb 2003.

-- RichardDonkin - 20 Aug 2004