Tags:
archive_me1Add my vote for this tag create new tag
, view all tags
(Moved from BackFromPreviewLosesText - this discussion is no longer relevant since there is a fix in TWikiAlphaRelease.)

-- RichardDonkin - 21 Mar 2002


Short-term Workaround/Fix:

This is really a workaround, since it has some disadvantages:

  1. Implement the RefreshEditPage patch - this ensures that the second edit in a session always goes to the server not cache, by causing every link to the Edit page to have a unique URL.
  2. In IE5's Tools | Internet Options | General, under Temporary Internet Files | Settings, choose Check for newer versions of stored pages = Never

This does fix the problem, by causing IE5 to prefer the cache on every page (except Edit pages). However, this is probably not suitable for most people, as it will cause many non-TWiki sites to appear to have out of date information, leading to confusion or requiring users to hit Refresh frequently. Choosing other IE5 cache options doesn't help, e.g. 'every time you start Internet Explorer' does not fix this problem (although it should!)

So, the hunt is still on for workarounds or fixes that are acceptable to most users - here are some options (which could be restricted to IE5 only):

  1. Remove the popup window links in the Edit page. Easy, but not helpful to novices.
  2. Re-do the popup help windows, avoiding the cache flush - one solution might be to pre-load the help text in the template for the Edit page, and then use JavaScript to populate the popup window. If this is not feasible, some other form of help may be necessary, e.g. a Favourites menu entry that loads a file from hard disk, if that doesn't have this problem.
  3. The Back button could have some JavaScript (when going back from Preview to Edit) that checks whether the same text is in the page? This could be done perhaps by passing some data into the Preview page, which is then checked on the way back... However, I'm not sure if this is really feasible. I think using JavaScript here would be acceptable, as it's a workaround for IE5 only and should degrade gracefully if turned off.
  4. Use JavaScript to break the Back button completely when going back from Edit, and suggest user hits Save - fairly nasty, though perhaps OK if user can go back to other pages in history. It would be best to do a 'back to Edit' button on the Preview page if we go this route (see below).
  5. Add a button to the Preview page to re-generate the Edit page from the Preview state, since the full set of edit text is saved in a hidden field in the Preview page. However, users will still press the Back button, so this doesn't really solve the problem unless we break this button (see above). This was already raised, along with this bug, on SaveAndContinueWorkingFromPreview, and on BrowserIssues.
  6. Use another browser. The only really good solution! This may be an option for some people (Mozilla, Netscape 4.x/6.x and Opera all work well if configured properly), but not for most large-scale intranet use of TWiki.

Some of the text here was refactored from BrowserIssues, contributors included HaJoKoehler and JohnBelmonte.

I've refactored BrowserIssues to reflect this better understanding of this area, and the usefulness of the RefreshEditPage patch.

Environment

TWiki version: Mar 15 2001 beta
TWiki plugins: InterWiki
Server OS: RH Linux 6.2
Web server: Apache 1.3.12
Perl version: 5.003_05
Client OS: Win2K
Web Browser: IE 5.01, IE 5.5 SP2 and IE 6.0 (bug on all versions)

-- RichardDonkin - 28 Oct 2001

I am currently rolling out an official install of TWiki after running an unofficial one for 6 months. And, wow, I had never managed to reproduce that before.

Anything as drastic that causes my users to lose data is going to be a show-stopper. My machine runs IE 5.5, but it is an exception in my firm as everyone else is 5.0 or 5.01 (and we are not supposed to update s/w ourselves).

TWiki version: Dec 2000 Production
TWiki plugins: none
Server OS: MS Windows NT 4.0
Web server: unknown
Perl version: unknown
Client OS: Windows 95
Web Browser: IE 5.00 (bug exists) IE 5.5 (bug does not exist)

-- MartinCleaver - 29 Oct 2001

Thanks for testing this - very interesting that IE 5.5 fixes this for you. The other detailed report of this bug, EditChangesLostAfterPreviewOnIE, also mentions IE5.0 was used.

However, on testing this with IE5.5 SP2 on the same machine, I get the same problem as before - perhaps something else fixed this in your environment?

-- RichardDonkin - 30 Oct 2001

Possible. I just tested again, this time with TWiki.org and I still don't have the problem on IE 5.5. Definitely needs to be a documented bug if it is not fixed at the TWiki end.

-- MartinCleaver - 05 Nov 2001

I have just reproduced this on TWiki.org with IE5.5. Try editing SandBox24 (it exists at the moment), adding one line, then selecting the TextFormattingRules link. Then go Preview, then hit the browser Back button, and the line you just added is gone.

Are you doing exactly this test? Try following this procedure on your local TWiki as well, and let me know if you get the same issue. I've just looked at my IE5.5 options and the 'check for existing copy of page' one is set to Automatically, and the disk cache is 20 MB - if you could check your caching options as per BrowserIssues it would be useful to see if that is somehow making it work for you.

-- RichardDonkin - 05 Nov 2001

I just tried this on TWiki.org from my home PC with IE 5.5 - I too get lose text in this situation. Perhaps I was mistaken in thinking it was fixed. When I get back to work (which may be the week after next) I'll give it another go.

Perhaps:

  • Andersens have patched my browser (they do have control over many of the settings)
  • Our server (IIS 5.0) caches things differently

Regardless, it is clearly not fixed for most users using IIS 5.5. (And I will have to work around this at work, I'll probably pre-load the TextFormattingRules topic beneath the editor window and remove the link).

-- MartinCleaver - 17 Nov 2001

Okay. I take back what I said about it working at work. It now doesn't. (I can't be completely sure that it never worked as my machine has been re-built since I first did my test).

-- MartinCleaver - 19 Nov 2001

Thanks for the update, and I hope you'll post the updates for pre-loading the help pages.

-- RichardDonkin - 20 Nov 2001

It seems my RefreshEditPage fixes this bug. I tried IE6 on twiki.org, and got the problem. I tried it on my patched twiki, and it worked! (especially people with IE5.0 & 5.5 should try it and see if it works also for them)

Please try it here: http://koala.ilog.fr/wiki/bin/view/Test/WebHome

-- ColasNahaboo - 20 Nov 2001

Thanks for the update, I'll try IE6 to see if that fixes things when using your site. I have RefreshEditPage working on our intranet as well, btw.

Can you post your IE cache settings? I found that RefreshEditPage fixed this on IE 5.x, but only if I set the cache options to 'never check cached page against site' - unfortunately, this applies to all sites, leading to an excessive amount of caching (particularly if you keep your browser open for days at a time) and use of Refresh to bypass this.

I would like to see RefreshEditPage included in the AthensRelease so that IE 5.x users at least have this option, and to fix the 'second edit in session' issue of course.

-- RichardDonkin - 26 Nov 2001

frown Didn't fix it for me, using IE 5.5 on Windows 2000.

-- MartinCleaver - 26 Nov 2001

I just tested IE6 on Colas' site, which uses RefreshEditPage, and it doesn't behave any differently to IE5.5 - i.e. if you set 'check cached page against site' to 'Never', then you don't get BackFromPreviewLosesText (exactly like IE5.5), but if you set this to 'Automatic', you get the same problem.

Martin, I'm not clear what you tried in 'didn't fix it for me' - if you are using RefreshEditPage, you need the settings mentioned here for it to help. Also, please follow exactly the steps listed in the Test Case at the top of this page.

-- RichardDonkin - 26 Nov 2001

Guess what? you are right my patch does nothing. I must have dreamed awake...

But, there may be a solution using my patch:

  • when you edit a page you edit actually a unique random URL, e.g.: http://koala.ilog.fr/wiki/bin/edit/Test/TestTopic5|%0e%05%0b%19
  • then, on preview, the trick would be to save this temp page in a cache (in a directory, e.g.: data/_cache/Test|TestTopic5|%0e%05%0b%19 ) Pages older than 1 hour (or the configured edit limit) will be removed by this operation
  • thus, if on a later "back", the TWiki engine is queried for this same URL, TWiki will re-give the cached temp page, not the original one

-- ColasNahaboo - 26 Nov 2001

Interesting idea - this could end up being a fair amount of work, but the SavePreviewTextOnServer idea would also require a similar temporary data store on the server, so maybe this could be used to implement both ideas. It would be important to age-out the cache, perhaps by running a cron job every few hours. It's annoying to have to do this much coding to work around an Internet Explorer bug, but it may be necessary...

Maybe you could comment on some of the options mentioned earlier in this page?

-- RichardDonkin - 28 Nov 2001

Well, they all include some javascript dirty work, and may lead to more browser-dependant problems than they try to solve. I think the "same URL, same contents" is actually the best guide to solve problems. And other browsers than IE could develop this behavior in the future...

-- ColasNahaboo - 28 Nov 2001

I just tried this (on twiki.org), using IE 5.00.2919.6307 wink and did not experience the problem.

Nevertheless, that's not why I'm writing this note. Maybe a temporary help would be to include a note at the top of the TWiki.TextFormattingRules page (or a link) that explains the problem clearly, succinctly, and with succinct instructions to avoid the problem?

The link could be in a sentence at the top of TWiki.TextFormattingRules like: If you use Internet Explorer 5, 5.5, or 6, please read this note to avoid potential loss of your edits.

Both the sentence and the note should be phrased carefully, I suggest that we not blame Microsoft / IE, but simply ascribe the problem to an incompatability. We might include a section that explains the problem in more depth that does describe the problem as a bug in IE (or a difference between how IE and all (?) other browsers handle certain aspects of web browsing. That description might reference this page, but this page is currently far too technical for the purpose I'm describing.

I may start work on such a page, but I may not, pending hearing whether anyone thinks it's a good idea. (I'd have to educate myself a little better on how to avoid the problem, which I might do by rereading this page and a few related ones.)

-- RandyKramer - 28 Nov 2001

Reproducing this on twiki.org is definitely possible - I've just added a step to the test case, to handle possible caching of the TextFormattingRules page (which may break the test case). Also, if re-testing this, you should always add a new line of text to the edit page.

The link at the top of the pop-up page(s) is a good idea, and would help avoid this, but I would prefer a fix, as this makes TWiki usage more complex than it needs to be. It might be a good idea to put the warning on the Preview page itself, near the top, since that is where the user needs to remember not to hit Back.

I tend to think of this as a bug, because setting the caching behaviour to 'once per session' implies that the browser should not check the cached Edit page against the server more than once per session, yet IE is doing this when the pop-up page is launched - hence it's an unexpected behaviour that contradicts user expectations of IE's cache settings page. However, I don't relish trying to get Microsoft to fix this!

Colas's suggestion, and SavePreviewTextOnServer, are probably the best option, as they make TWiki much less vulnerable to this and other browser bugs/misfeatures, and the JavaScript hacks above could have their own problems, and of course won't work with JavaScript turned off by the user.

-- RichardDonkin - 29 Nov 2001

I know this topic has been beaten to death for over 6 months now. Having used several different Twiki skins, I can definitely say that the "preview" mode is more trouble than it's worth. I think the best approach would be to replace it with an "Undo" mode (where the system would revert a version provided you were the current owner and there were no other locks on it). We are using a "non preview" skin where I'm at now with 100% success. I could never say that with the preview mode, since some people (inspite of the warnings on the page) wouldn't save their preview.

-- DavidWeller - 29 Nov 2001

A non-preview mode may be a good idea, but the problem isn't with Preview mode - it's with people hitting the Back button, resulting in loss of text. There is nothing to stop people from hitting the Back button from the saved page, and they probably will if they notice they have made a mistake - the Back button is always visible, whereas they have to scroll to the bottom of the saved page to hit the Edit link.

-- RichardDonkin - 30 Nov 2001

I still have not duplicated the problem using IE 5.00.2919.6307 on Win95 (OSR2), even with RichardDonkin's revised test case. I don't know if I'm lucky or have just stumbled across some secret setting that avoids the problem.

I will make a few caveats to the above statement.

  • For the last two days my access to twiki.org has been very flaky, and I'm seeing quite a few other problems, but I am not losing my text when following the instructions listed above. (Aside, I've been using three different back buttons -- the keyboard shortcut, the dropdown menu, and the mouse right click menu.) (Those other problems are mainly of the nature of getting the "This page cannot be displayed" result one or more times when attempting an edit or preview -- this occurs whether I am attempting to perform the test as described or am simply browsing and occasionally editing TWiki.)
  • So far I cannot tell you anything about my browser cache settings. I checked under Internet Tools --> Advanced but don't see anything that looks like a browser cache setting (or any phrase like 'once per session').

There is one other piece of flakiness I'll mention that happens all the time. I don't think it is related at all to the problem, but ??? (and, it may provide a clue as to how my browser is set up):

  • Quite often I enter the URL for the WebChanges page in my browser address bar (http://twiki.org/cgi-bin/view/Codev/WebChanges) and then press enter to get the page. It presents the current (i.e., most up to date) page.
  • Then I'll press <ctrl>n to get another copy (browser window), but this time the page is not the current page, it appears to be an older (and I guess cached) copy -- I have to refresh it to get the current page.

If someone thinks I've stumbled across the magic formula and wants me to check some specific setting of my browser, let me know where to find it and I'll report back.

-- RandyKramer - 30 Nov 2001

Tried again today, still can't duplicate the problem, and the general flakiness I mentioned above is gone. (I suspect that was a result of a backbone outage somewhere that I've heard about -- it affected the "UO"??)

-- RandyKramer - 01 Dec 2001

Interesting... I don't think it matters which Back button you use, but I did all my testing with the main Back button on the IE toolbar.

The cache settings are in IE's Tools | Internet Options menu, under General tab | Temporary Files | Settings. You are probably using 'Automatically', the default, but it would be good to know!

The twiki.org flakiness is something I've had as well, but in theory should not affect caching (other than to make it very obvious when the Back from Preview uses a non-cached Edit page, because it will probably give a 'not found' type error). You could try Colas' site, mentioned above, if twiki.org is too flaky, but it seems OK at the moment.

It would probably be best to start with a new browser session (close all IE windows first) to see if that helps reproduce this - perhaps the bug behaves differently after the first access to the Edit page or the pop-up help page. MartinCleaver also had the bug on Win95, so I don't think it's the OS difference.

As for the WebChanges behaviour - that's a bit odd, and certainly not what I'd expect from any cache settings. It's almost as if IE is not caching the latest copy of WebChanges, and is using an out of date cache; or perhaps it is going to disk cache although the memory cache has a more up to date copy... If IE was going to the server (as in the main 'back from preview' problem) it would always get the latest correct state, since WebChanges is of course generated and not an 'edit state' page. Indicative of something rotten in the state of IE caching, at any rate smile

-- RichardDonkin - 01 Dec 2001

  • Oh, the back button on the toolbar -- I forgot it even existed, I don't know when I've had the toolbar on. Anyway, just tried that, same results (i.e., I cannot duplicate the problem).

  • You are correct, the cache is set to "Automatically".

  • I agree the flakiness should not have been causing the problem, and the flakiness is gone now (ended sometime yesterday).

  • I will try again with a new browser session -- it's not convenient to close IE right now as my typical approach is to have lots of unread or partially read windows open. I'll work towards shutting it down today or tomorrow (and then I'll reboot Windows) and try with a new browser session.

  • The WebChanges behavior -- today for the first time ever (IIRC) it did work "properly" -- the new window did show the latest WebChanges page. I'll retest this a little later to reconfirm it, but did anybody change anything??

PS: I agree with the wording of the warning, but if you ever have another reason to edit it, consider replacing "where your changes might get lost" with "which might cause your changes to be lost" or something similar -- the first expression sounds a little bit, can't think of the right word, so I'll say "slangy", in other words, slightly less than fully "professional".

-- RandyKramer - 02 Dec 2001

I did some more testing, after a reboot of Windows (and fresh start of IE5) and still cannot duplicate the problem.

PS: Today the WebChanges page worked the way it always has for me <ctrl>n display a cached WebChanges page, the occurrence on 02 Dec 2001 must have been some kind of fluke.

-- RandyKramer - 04 Dec 2001

For now I added this note at the bottom of the edit screen:

NOTE: There is a bug in Internet Explorer where your changes might get lost. Do the following in case you return from Preview to do more changes and your changes are gone: Go forward again in your browser (don't click on Preview) and save the topic.

Let me know of I should change the wording.

-- PeterThoeny - 02 Dec 2001

Thanks for putting the warning in, the text is fine given the space limitations. If it's OK to use a bit more space, it would be good to use the following (I've simplified the sentence a bit as well) - it's 320 bytes vs 240 bytes for the original, so you might want to use a smaller font:

NOTE: There is a bug in Internet Explorer where your changes might get lost, particularly if you use the pop-up help links in this page. If you press Back from the Preview page to do more changes and your previous edits are gone, just press the Forward button in Internet Explorer (don't click on Preview), then save the topic.

There is an argument for putting this warning at the top of the Preview page, since this is close to the Back button on screen, but that would force everyone to read this message even if not using IE, so I think it's OK on the Edit page. Although it would be nice to provide a link to the TWiki page on the bug, this would, ironically, make the bug more likely, so it's best avoided. We could perhaps include a non-link reference, e.g. 'see Support.BrowserIssues on twiki.org', but that's still more text!

The real solution, IMO, is to store the edit state on the server (as an option) and use this to refresh the Edit state from the actual previewed value. The warning will help a bit, but quite a lot of people may not fully read and understand it.

-- RichardDonkin - 02 Dec 2001

Comments added above, directly after RichardDonkin's comments of 01 Dec 2001.

-- RandyKramer - 02 Dec 2001

The other option is to make the preview screen a pop-up. That way the text-box edit area is retained and only a browser crash or user-error will result in lost edit state.

The decision then would be where to place the save button. On the edit screen or on the save popup screen.

-- NicholasLee - 02 Dec 2001

What was wrong with the general idea of SaveAndContinueWorkingFromPreview?

-- MikeMannix - 02 Dec 2001

Of course that works as well. Sometimes though you might prefer to finalise an edit before committing anything. Particularly when 'rushing' into commenting on something then deciding not to actually commit a comment to the TWiki.

I'm sure its possible to get both to work together, just a matter of working out the usability.

-- NicholasLee - 02 Dec 2001

Given the popularity of IE5, monopoly rules kinda make an IE problem a TWiki problem, too. The alarming bug note in Edit mode doesn't inspire confidence in IE users or otherwise - losing your work is...extreme. Fixing this any reasonable way possible now, and refining later, seems to make sense. SaveAndContinueWorkingFromPreview - the save-and-go-directly-back-to-Edit version - appears to do that.

Also, aren't undos still possible if the re-edit is done quickly? RCS doesn't commit every save as a revision - what controls that, the edit lock timer setting? So you can still keep changes off the record.

The other Preview-vs-Save-Save-Again argument is the good old save-often rule. I set autosave in word/text processors to max five minutes. If a significant percentage of TWiki users spend five minutes or more writing, or formatting a table or something, using edit-save-edit to preview would also be a safety feature to me.

And really, even without the RCS grace period, there are only those cases where somebody might be embarrassed by something they ALMOST posted... In that mode, they'd be safer writing offline and pasting when they're sure. IMHO.

-- MikeMannix - 02 Dec 2001

To address Nicholas' point - a pop-up Preview page is an interesting idea, but it does tend to proliferate windows. Some browsers (e.g. Opera) have features intended to prevent pop-up ads that would stop this working, but that is a matter of setup. I would rather see a solution that does not change the current UI just to work around a specific browser bug - there are other IE bugs that would not be solved by this (e.g. Save sometimes doesn't save the right text, see earlier for details) but could be fixed by holding Edit/Preview state on the server.

SaveAndContinueWorkingFromPreview doesn't, unfortunately, completely solve the problem, although it does make it less likely perhaps - if people are used to hitting the Back button, as they are from many form-filling websites, they will just use Back and run into the issue. The only 100% effective solutions IMO are to either pre-load the pop-up pages (a workaround) or to bypass IE5 caching altogether by storing Edit/Preview state on the server (see SavePreviewTextOnServer and Colas' suggestion above), and reloading this explicitly each time you revisit a page through Back or Forward. If we add a 'save but don't publish' button to the Edit page, which updates the server-based Edit/Preview state, then we have the security of SaveAndContinueWorkingFromPreview without having to publish interim changes.

BTW, I am on a trip for the rest of this week and may not have easy Internet access, but will participate again when I return!

-- RichardDonkin - 03 Dec 2001

Whooops, I kinda imagined an extra step, above: save-and-go-back-to-edit only backs up the changes, no Preview... So, if there's just a Save, there's still a drastically reduced Back button problem. Preview Changes implies, and says on the page, that you can go back to continue - but Save is clearly the end of that edit. So people takes their chances using an undocumented Back, same as with Web forms - some preserve results, some don't. And if their changes are gone, they won't be surprised - as long as they don't save again, all's well, they can cancel, go forward, reboot their machine...

So it comes down to how negative it would be not to have a Preview feature, since it's a common option, and with RCS on TWiki, probably more desirable than in some other places - explaining the RCS grace period doesn't sound too efficient.

Then again, you could have a countdown clock by the edit lock, tie in that function, have a Save As Preview that lets you know that you haven't released the lock - separate template - and a Final Save that resets the lock. (I remember a program that showed you a countdown to autologout unless you refreshed, as a security thing, and that made sense, wasn't weird.) Does any of this make sense?

It just seems like such an annoying thing that's been discussed forever, and now it's IE6, IE5 won't be going anywhere for a while, and the note in Edit - that's alarming, losing data is the worst, so it makes TWiki sound...unsafe.

BTW, click the Release edit lock help link in Preview, the grace period is explained... ! Except the Release doesn't actually seem to reset, or force the revision to be committed???? How come...??

-- MikeMannix - 03 Dec 2001

Added the NOTE to the edit screen and updated TWikiAlphaRelease and TWiki.org.

Changed the TopicClassfication to FeatureEnhancementRequest since the problem is now somewhat defused.

-- PeterThoeny - 03 Dec 2001

I did some more testing, after a reboot of Windows (and fresh start of IE5) and I still cannot duplicate the problem. I will copy this note above, closer to the thread (i.e., right after the sequence of my comments of 30 Nov 2001, followed by RichardDonkin's comments, followed by my comments of 02 Dec 2001.

Aside: The new note on the edit page looks good!

-- RandyKramer - 04 Dec 2001

With regards to the RCS grace issue. The idea would be not to commit the edit-to-preview-save data to the 'HEAD' Topic node until a preview-to-save-save. I actually fiddled with this idea back when I hacked a CVS backend version of TWiki.

In a lazy-locking or cluster type enviroment saving the preview data to a temporary location is more practical.

-- NicholasLee - 04 Dec 2001

How about removing the reason to use the back button?

Slashdot appends the edit box to the bottom of the preview page, giving you the option to continue editing, save now, or preview again. This works very nicely and eliminates the need to backup after preview.

As long as a hybrid TWiki preview/edit page clearly delineated the end of the preview section, it could work out very nicely.

Any thoughts?

-- JohnAltstadt - 19 Jan 2002

I think adding an edit button to this page is not a bad idea (see SaveAndContinueWorkingFromPreview for some discussion), but it's not a complete solution - particularly since on most pages you'd have to scroll to the bottom of the page to get to the 'Edit again' button, whereas the browser's Back button is right there.

As I mentioned above, I think the only effective solutions are:

  • pre-loading the pop-up help pages - this avoids the most common cause of this problem in IE5, but starting another IE5 browser window can also cause this (I had this the other day on TWiki.org, even though I'm well aware of this issue). Not a great solution for those who don't use JavaScript, and quite browser-dependent of course.
  • store Edit/Preview state on the server (as in SavePreviewTextOnServer), and re-retrieve this every time you go (back or forward) to the Edit page, i.e. bypass IE5 caching completely since it is so broken. This is a better solution IMO, and should also fix a less common IE5 data-loss problem. However, it involves significant TWiki code changes.

One thing to explore is whether the LastModifiedFieldOfHttpHeader could be set carefully on the Edit page so that IE5 will always cache the data for (say) 1 hour - i.e. to take more control of the browser caching process to avoid data loss. This would require RefreshEditPage to be implemented, but that is a requirement for Opera in any case (to avoid 'second edit loses changes from first edit' problems). I have recently got the LastModifiedFieldOfHttpHeader stuff working, see that page for the patch (but let me know if you want to use this as there's some slightly better code available that sets the Content-Length as well, which some browsers may use in making cache decisions.)

There is some good information about cacheable CGI at http://vancouver-webpages.com/CacheNow/detail.html#CGI - the rest of this page is also good on the details of how caching works, which is a big part of this problem. A side-benefit of getting more control over caching is that the amount of load on TWiki sites could be controlled, and users could see better performance through increased caching as well.

-- RichardDonkin - 19 Jan 2002

UPDATE: Hard to believe after all this time, but I think I now have a complete fix for this problem, tested on IE6 with patched March 2001 beta TWiki. I've tested this a lot and am quite happy that it works, but it would be great if other people could test it in their environments, and with IE5.x and other browsers.

I applied the following code:

  1. Patch (included below) to the edit script that sets cache-related HTTP headers (Last-Modified, Expires and Content-Length) - these cause IE6 to always cache the Edit page when you hit Back from Preview, even when you create a new window (pop-up or a full browser window).
  2. RefreshEditPage patch to the view script - this is important to defeat the aggressive caching resulting from (1), by generating a unique URL for each Edit request on a given page in the same session, forcing the browser to go to the server.

I also tested this on Opera 5.12 and Mozilla 0.9.7 without problems.

The main patch is as follows:

    $tmpl =~ s/%TWIKICAT%/$tcat/go;                  # Unchanged

# RD: 19 Jan 02, add the Last-Modified, Expires and Content-Length HTTP headers

    # Required format: Last-Modified: Thu, 23 Jul 1998 07:21:56 GMT
    # Get time now in GMT as string
    my $lastModifiedString = gmtime();
    $lastModifiedString =~ s/ /, /;             # Comma after the day
    $lastModifiedString =~ s/$/ GMT/;

    # Add the HTTP headers - note that putting this in the HTML <META> element
    # has no effect on many proxy caches, because they only look at the HTTP headers.
    my $expireHours = '1';         # Expire after this many hours
    my $expireSeconds = $expireHours * 60 * 60;
    print $query->header(-content_type => 'text/html',
                         -content_length => length($tmpl),
                         -last_modified => $lastModifiedString,
                         -expires => "+${expireHours}h",
                         -cache_control => "max-age=$expireSeconds"
                         );

# RD: 19 Jan 02, end of last-modified changes

    print $tmpl;     # Unchanged

It is important to also comment out the earlier line (about line 216) that sets one header:

    print "Content-type: text/html\n\n";

This patch is basically the same code I was using in the view script to improve caching of viewed pages, so it checks the pre-editing data file for the last-modified time.

Let me know how this works for you. I hope it can make it into the BeijingRelease alongside RefreshEditPage, as it only requires these headers on the edit script, i.e. it won't affect cache behaviour at all for the normal view case.

I notice this is classified as a FeatureEnhancementRequest - it should really be a BugReport IMO, particularly since there is now a fix and it adds no new features smile

-- RichardDonkin - 19 Jan 2002

Richard - that sounds great I'll look it over and work into CVS. I might need to do something with the header information so that the writeHeader method cuts in, this is so there is still the ablility to store cookies when needed. I've changed the status to BugAssigned.

-- JohnTalintyre - 20 Jan 2002

I've simplified the patch above - it now just uses the time now for Last-Modified, and doesn't set the %LASTMODIFIED% variable (which of course should never be done in Edit - quite entertaining seeing it calculating new time on refreshing Edit page, though!). I've tested this locally and it works OK even though my server time is over 1 hour ahead of my client PC's time - presumably the Expires is what makes the difference.

I would like to add a Cache-Control headers to this so that HTTP/1.1 proxy caches can do a better job, but that's not essential. See BrowserAndProxyCacheControl for discussion and links on this area.

You can assign cookies through CGI.pm, with $query->header (see this CGI.pm manual page) and other CGI::Cookie stuff.

Once all this is tested, someone can take out the scary bug message from the template as well smile

UPDATE: Have updated the code above again, latest version sets the cache-control header for use by HTTP/1.1. I don't think any other headers are necessary.

-- RichardDonkin - 20 Jan 2002

The code in TWiki.pm changed some time ago, so there is now a writeHeader method, this can be picked up by Plugins. Everything in the patch could be done from a plugin (using $query to detect the edit script), except for knowing the length of the content. I suggest we add the content length to the writeHeader method. Additionally I suggest the above becomes the default behaviour for edit if a plugin doesn't take over writeHeader and that the cache expiry time becomes a preferences variable that can also be used with HTTP_EQUIV_ON_EDIT.

I have just tried this on my machine (just the header stuff) and it didn't work, mind you, I always lose text on this IE6 browser when going back after preview.

-- JohnTalintyre - 23 Jan 2002

Thanks for trying this out - I really need to upgrade to the latest release, wasn't aware the Sept code had changed in this area. Good to hear that the code is more modular now, and that the default behaviour will be to fix this bug - some people may want different headers for specific caching behaviour, particularly on view pages.

I'm interested in why this didn't work - were you going via a proxy cache of some sort? If this is a non-transparent cache, could you try disabling use of the proxy to see if that helps? If you have a copy of wget (on most Linux boxes and CygWin), try wget -S http://yourtwiki/ - this will show you the headers sent. Also, you could try JunkBuster between your browser and server - it's an ad-busting proxy with options for showing all headers (try single-threaded, debug 8 and debug 16 in its config.txt file, in version 2.9.10 for Windows, downloadable from http://sourceforge.net/project/showfiles.php?group_id=11118 ).

Cache expiry time should definitely be a TWikiPreferences variable - here are some variables that would cover different types of TWiki operation:

  • CACHE_EXPIRY_EDIT - how long the Edit page should be cached - since it uses RefreshEditPage this is only used by the browser's Back button, so it could be very long by default (e.g. 24 hours). A long time minimises the risk of someone losing text, even if they leave their session for a day. If we make this longer than the lock time, they should of course have lost the edit lock, but providing that doesn't confuse TWiki they could still get to their text and save it as a new page, or copy/paste as a comment to the new version of the same page. Not losing text is my main concern here.
  • CACHE_EXPIRY_VIEW - this would apply to most View pages, and might be anything from 0 to 8 hours, depending on how quickly the TWiki site expects to change. I think 8 hours is probably too long except for a very static site, and the default should perhaps be 0 to avoid confusion. 30 mins may be a good recommended value (but not a default) since that lets you go back through history without refetching pages, while still showing you updated pages fairly quickly.
  • CACHE_EXPIRY_DYNAMIC - this would apply to any View page involving a search, e.g. WebChanges, and pages that use some other dynamic TWikiVariables. [This would mean a larger change to figure out which variables mean the page is dynamic - if this is too hard to do, we could start with just the CACHE_EXPIRY_EDIT variable and leave the other two for later.] This should also apply to the View page generated on hitting the Save button, to avoid confusion (as discussed in SavePreviewTextOnServer).

The remaining types of page are Preview, Attach, etc. Preview should probably have the same caching rules as the Edit page, and be covered by CACHE_EXPIRY_EDIT, including use of RefreshEditPage (although Preview page caching on Back/Forward always seems to work in IE5/6 anyway); the other types could probably be uncached and covered by the _DYNAMIC case, as they are less frequent.

I'm not sure there's much point in using the cache expiry in HTTP_EQUIV_ON_EDIT, particularly since the Expires header takes a date and the most convenient format for CACHE_EXPIRY_EDIT is hours or days (e.g. 2h or 1d) - the META tags are only used by some browsers, whereas virtually all browsers and all proxy caches use the HTTP headers. The caching-related META tags are mainly used by people who don't have the ability to set the HTTP headers, and don't realise they are mainly ignored.

-- RichardDonkin - 23 Jan 2002

Topic revision: r1 - 2002-03-21 - RichardDonkin
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.