This page covers various web browser issues - these are generally quite minor, but worth knowing about. (Also, see BrowserFormattingIssues
for details of how browsers format TWiki text, mainly white space.)
Browser Cache issues
Back from preview loses text
: In the TWiki Dec 2001 release and earlier, doing Back from Preview will not
return you to the previous state of the Edit page, i.e. some of your edits appear to have been lost (see BackFromPreviewLosesText
, fixed in TWikiRelease01Feb2003
). This happens most frequently in IE5 or IE6, though it can happen in other browsers with the wrong cache setup. The fix in TWikiRelease01Feb2003
works virtually all the time, but it does still happen very occasionally when IE decides not to cache the Edit page's state.
: you have not necessarily lost anything. At least in IE5/IE6, you can hit the browser's Forward button to get back to the Preview page, which does have your latest text - just hit Save, and then Edit. This happens because your browser didn't cache the Edit page state properly, and instead fetched it from the TWiki server (typically because you are using IE5 and you consulted a popup help window from the Edit page, e.g. TextFormattingRules
fix is well worth applying to your local TWiki, even if you are not yet using TWikiRelease01Feb2003
, as it can be quite demoralising to new users to lose their work. In one case I've seen, the user didn't notice that the first change was lost on doing a re-edit by going back from Preview.
: If you are still getting this problem on a TWiki that has this fix applied, try the following:
- Check your browser #Cache_setup - if it is set to 'always check the site for new pages' it will cause this problem
- If the TWiki site is using SSL (i.e. https:// links) and you are using IE, set InternetExplorer to cache SSL protected pages - see Tools | Options | Advanced, scroll to the Security group, and uncheck Do not save encrypted pages to disk. If your TWiki site content is highly confidential you may not want to do this - you could set the option to clear disk cache (temporary Internet files) on exit to get some security.
- Check for any use of proxies and particularly proxy caches - try to bypass if possible, and try to find out if transparent proxy caches are used by your organisation or ISP. If you can't bypass them, as with transparent caches, see the next step.
- Check the headers delivered by TWiki on an
edit page - if they include Last-Modified and Expires, the fix is 'working' in its terms. See BackFromPreviewStillLosesText for the use of the
wget command, available on most Linuxes and downloadable for Unix and CygWin (see Google:wget).
- If you still have a problem, please log this as a BugReport including details of your cache settings, proxy usage and exact browser and OS version. It's best not to add new bug reports to BackFromPreviewStillLosesText (see SupportGuidelines).
Second edit in session uses old data
Depending on your browser and cache settings, you may find that the second Edit of a given page in one session seems to 'ignore' the changes you made in your first Edit. This happens because your browser is using the cached version of the previous Edit page. The simple workaround is to hit Refresh or Reload, but the real fix is to upgrade to TWikiRelease01Feb2003
- if you don't want to upgrade yet, just implement the RefreshEditPage
In general, there is a conflict between the browser caching that you want in 'back from Preview' (aggressive in-memory caching) and in 'second Edit this session' (check cache against server and fetch latest page) - hence the need for this patch to differentiate the two cases.
Most browsers have a feature controlling how frequently they check that their cache has an up to date version of a web page. For TWiki use on an intranet, setting 'check once every session' is typically best, and documented below since it is usable for most other browsing as well. However, this means that you may need to hit Refresh/Reload when editing a page for the second time in a session - the fix is to implement RefreshEditPage
(included in TWikiRelease01Feb2003
NOTE: If you use InternetExplorer, be sure to apply the BackFromPreviewLosesText patch (included in TWikiRelease01Feb2003).
- Browser details for setting 'once every session' checks on cached pages (normally these are correct by default):
- IE5.x and IE6.x: the default is OK. To reset this, go to Tools | Internet Options | General, under Temporary Files | Settings, and choose 'Automatically'.
- IE4.x: Go to View | Internet Options | General, under Temporary Files | Settings, and choose 'Every time I start Internet Explorer'.
- Mozilla 1.x, Mozilla Firebird 0.x and Netscape 6.x (or higher): Go to Edit | Preferences | Advanced | Cache, and choose 'Once per session'
- Netscape 4.x: Go to Edit | Preferences | Advanced | Cache, and choose 'Once per session'. Also, make sure that the Memory Cache is greater than zero.
- Opera 4.x, 5.x, 6.x, 7.x: Opera caches quite aggressively, so expect to Reload frequently. In 'File | Preferences | History and Cache', under Documents | Check Modified, set 'Days, Hours, Min' and select something reasonable (e.g. 8 hours). Make sure that RefreshEditPage is implemented on your TWiki server, to avoid frequent Reloads (built into TWikiRelease01Feb2003).
- Alternatives to changing browser cache settings:
- Users can refresh every Edit page explicitly (but don't do this if you went Back from the Preview page, as you'll lose your edits!). Ctrl/Refresh on IE or Shift/Reload on Netscape/Mozilla are required to always bypass caching.
Browser-specific issues and features
- Netscape 4.x generally works fine with TWiki, with this caveat:
- Opera does aggressive caching by default. Implementing the RefreshEditPage patch (included in TWikiRelease01Feb2003) is highly recommended to avoid hitting Reload all the time (and to avoid losing edits by editing an old version of a page). See the discussion at #Browser_Cache_issues.
- Opera 6 may try to display plain text attachments as HTML, even when the server delivers them with the
text/plain MIME type - if so, go to Opera's Preferences | File Types dialogue box, and select 'Determine action by MIME type'.
- - Opera 7.01 or higher renders the table in search results (e.g. WebChanges) strangely, without real columns for results. Now fixed by a TWiki HTML template change - see MinorBugs and apply patch to
search.tmpl, included in TWikiAlphaRelease as of 01 Sep 2003.
- Lynx mostly works OK with TWiki.
- Uploading binary attachments did not work with Lynx 2.8.4rel.1 on Cygwin - see LynxFileUpload. However, Lynx 2.8.5 (stable) should work fine - tested OK with 2.8.5dev.16 on Cygwin.
- Links is similar to Lynx but with table support - it doesn't prompt to authenticate the user on editing as of Links 0.96, but is OK for viewing.
- w3m is a Lynx replacement. It handles tables well and uses the default text editor via shell variables. It was designed as an HTML "text pager" but has turned into a better Lynx than Lynx. Key bindings can be set to mimic the Lynx command set. Highly recommended. See also W3mBrowserIssues.
- Macintosh users can search TWiki pages through the Sherlock search engine tool - see SherlockAndMozillaSearching, which should work with any browser, and see MacOS for more on Macintosh issues and features.
Related pages: BrowserExtensions
- making it easier to track changes using sidebars and other browser features
See also the following pages where contributions have been moved:
Next step for this material
The TWiki web has links to user docs and admin docs. Please go ahead and create/edit topics in the TWiki web here at TWiki.org. The core team will review it and take new content over to the non-public Beta installation (which is the master site also for production releases.)
- 09 Jun 2001
- 'View after save' problems: There seems to be a very intermittent bug with IE, Mozilla and Opera (i.e. probably not a browser bug) - hitting the Save button from the preview page sometimes doesn't (appear to) save the latest changes just previewed! See ViewAfterSaveCachesOldPage for details. Please comment there if you have seen this bug!
More comments go here :)
Rearranged some stuff related to w3m and moved all related stuff to W3mBrowserIssues
. Oops, changed my mind — added another pointer to W3MBrowserIssues here, but left the comments / recommendation.
- 12 Apr 2003
Minor updates to point to TWikiRelease01Feb2003
- 24 Jul 2003
To me this looks like the information that is still valid here should go into a supplemental doc, like already stated in TWiki.BrowserIssues
(so this support issue can be closed). I will open an issue on it with our tracker (Bugs:WebHome
- 26 Jun 2006
The "Second edit in session uses old data" bug hit me again. It happend on a twiki 4.0.4 and twiki 4.1.2 (with firefox as the browser). Any ideas?
- 14 Apr 2008
I found a fix. see EditAfterSaveShowOldContent
- 14 Apr 2008
I am closing this very old question.
I have TWiki 5.1 installed on our Linux platform. I am using Windoze 7 with Firefox 8. When I edit a TWiki page, it works ok, but the Preview AccessKey
does not work. Cancel, save, quietsave work ok, but not preview. Also, there is no button active for preview.
Install settings are default with basic configuration and Apache web server. Am I missing some config setting somewhere?
Oh, same results with IE 9. I do not have another (older) system to test on. It's looking like Windows7 remaps shortcut keys somewhere but I want to make sure TWIki is setup ok. I'm more curious as to why the Preview button is not appearing on the page.
Mike: Best to open a new support question for getting help and easy tracking.