Tags:
create new tag
, view all tags
NOTE: this feature request is attempting to fix what appear to be two bugs, one cache-related and one not - see ViewAfterSaveCachesOldPage and ViewAfterSaveLosesText. --Main.RichardDonkin

We've had an number of instances at DrKW of text being lost by the browser when trying to save from the preview page. TWiki renders the text on the preview page and also stores it in a (large) hidden variable. A possible alternative is to not pass the hidden text to the browser, but to instead store it on the server:

  • Press preview on MyTopic, store text in data/Test/MyTopic.tmp
  • Press save, read text from MyTopic.tmp, delete file
  • Save to topic as now

This takes advantage of TWiki's locking mechanism i.e. only one person editing at a time.

Advantages:

  • we don't then need to do the careful escaping need by various browsers that's need to store topic text in one hidden variable
  • avoids bugs we're seeing in IE
  • faster - not sending text back to browser
  • after preview text is on server, could be recovered if browser fails

Disadvantages:

  • lose the non-session basis of browser interaction i.e. some state on server. I feel this is not so bad because the lock file already does this.
  • If no save is done then preview file stays on the server. Replaced on next preview and if required such feels could be reaped if more than x hours old.

Thoughts?

-- JohnTalintyre - 28 Jun 2001

I've had this a few times in IE and it is quite confusing even though I use TWiki a lot - could be a usability issue for novice users.

It would be good to find out exactly where the bug is - probably it is in IE, but worth documenting under BrowserIssues in which browsers this bug does happen. I don't use other browsers on TWiki enough to really tell whether this bug happens or not.

One thought - why not extend the lock file to contain the preview text? It's already there, and already reaped after a certain time.

-- RichardDonkin - 28 Jun 2001

I actually did something like this way back at the start of last year when I was trying out cvs as a drop in replacement for rcs. Something like MyTopic.tmp probably wont work because you have the issue of multiple users editing a page at the same time. My method was to place the temporary file in data/Main/User/Web/Topic.txt.

The added advantage of storing the preview text on the server-side is that you'll make the save cycle faster, since at present a edit-preview-save involves sending the the modified text buffer to the server twice and back to the client once.

Probably the best logic would involve, always replacing the tmp file on a edit->preview, and using then deleting the tmp file on a preview->save.

It gets a little complicated though since you have to consider the edge cases when two people are editing a Topic at once. Possible if someone ignores a topic lock, or say someone leaves their browser for whatever the lock period is, returns and commits the modified buffer. In the meanwhile someone else has edited an 'unlock' page and committed it.

PackageTWikiStore is planned to handle all of that transparently, even on RCS.

-- NicholasLee - 28 Jun 2001

My consideration was that two people editing at the same time was no better with the current scenario and storing in one location (where directories already lived) saved some effort.

-- JohnTalintyre - 28 Jun 2001

Unless person A commits person Bs buffer.

-- NicholasLee - 29 Jun 2001

That's clearly possible, but much less likely that A overwriting Bs changes. Still point taken, this scenario can be avoided. Could have file of name ATopic.username.tmp.

-- JohnTalintyre - 29 Jun 2001

See BackFromPreviewLosesText for a variant of this idea suggested by ColasNahaboo recently, which would store the preview text on the server (actually the edit state but this is the same I think) in order to bypass the IE5 caching bug that is causing BackFromPreviewLosesText. I prefer the idea of keeping the temporary files in a separate directory as suggested by Colas, for easier purging by a script. If you use his random number suffixed URLs, it also gets around the problem of two users editing the same page after breaking the lock.

-- RichardDonkin - 28 Nov 2001

I've had this a few times using IE6 (or at least what I think is the same problem). Here's what happened just now on twiki.org, and a workaround related to BrowserAndProxyCacheControl - let me know if this is the same problem, and if the workaround helps. (It would be best to log a BugReport about this with steps to reproduce, I'll do that if this is reproducible.)

  1. Edit a page on TWiki.org at least once, preview and save it.
  2. In same browser session, edit the page again, make a change, then Preview and hit Save Changes
  3. Browser displays previous state of the view page, i.e. state after step 1
  4. With IE5 or IE6, try hitting Ctrl/Refresh to do a 'hard reload' (should bypass all caches) - this shows the latest state of the page, indicating that the Save actually worked.

I was using the JunkBuster non-caching proxy for this test. See BackFromPreviewLosesText (now fixed by cache control headers) for some discussion of caching issues, as well as BrowserAndProxyCacheControl - if this is really what's happening in this problem, all that's required is that the view URL generated from the save script needs to have suitable no-caching headers to ensure that the browser never shows a cached version of the page.

-- RichardDonkin - 20 Jan 2002

Why do you differentiate the view url from save from other ways of getting to the view url?

-- JohnTalintyre - 20 Jan 2002

Ideally, the page displayed after Save would never come from any cache, but directly from the server; other view generated pages should (probably) come from the cache subject to an expiry time (perhaps 1 hour) in order to simplify use of the history list and reduce server loads. It might be a good idea to generate the view-after-save URL to use a random or time suffix (as in RefreshEditPage), ensuring that it is never found in any cache when it is first used, but enabling it to be cached from that point onwards (so that going Back in browser to this page works OK, as in the fix for BackFromPreviewLosesText). The only downside of this is that people would want to bookmark view URLs and the suffix is messy, but the bookmarked URL would still work as the suffix is stripped out automatically.

However, all this is assuming that this is a cache-related problem - since it's intermittent and I was able to resolve my instance of this problem using IE5 Ctrl/Refresh, I suspect that it is, but it would be good to get confirmation.

If you are using a proxy cache for TWiki, as I think you said you were, the chances of it being cache-related go up quite a bit.

-- RichardDonkin - 20 Jan 2002

I'm reasonably confident that I have seen this problem at work where we do have a (infact several) proxy cache.

-- JohnTalintyre - 20 Jan 2002

I just clarified my comment above about how the 'view URL with random/time suffix' should be cached. If you do get this problem again, hit Ctrl/Refresh on the View page and see if the latest page is retrieved - if so, it's a caching problem.

-- RichardDonkin - 23 Jan 2002

I just had this again at TWiki.org when editing FeedReader - I did one edit to add some text, another edit to delete it, and then a final edit to add some (different) text. The View page generated after the final Preview omitted the third edit's text, but a Refresh using IE 5.5 showed the correct final version. Since I was using a proxy cache at the time, I think this is more evidence of a cache-related problem, as mentioned above.

I've changed this to BugReport since I think it's a cache-related bug, hope that's OK.

-- RichardDonkin - 12 Feb 2002

John - could you provide a bit more info about your proxy cache setup (transparent or not?) and browser/CGI.pm details, ideally by adding to ViewAfterSaveCachesOldPage, or ViewAfterSaveLosesText? There are really two bugs here, one cache-related and the other not.

I'd like to nail the underlying bugs using a simple BrowserAndProxyCacheControl or whatever, but there needs to be a better way of reproducing them - and I've just had the non-cache-related variant...

I've changed this back to FeatureBrainstorming as it's mainly discussing how to fix ViewAfterSaveCachesOldPage, which is not yet well characterised.

-- RichardDonkin - 19 Mar 2002

Edit | Attach | Watch | Print version | History: r16 < r15 < r14 < r13 < r12 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r16 - 2002-03-19 - 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.