create new tag
, view all tags
This page is dedicated to issues with the Mozilla browser.

See BrowserIssues and BrowserFormattingIssues.

Aside: I will not report bugs to Mozilla for older versions of Mozilla unless it is confirmed that they still exist in a currently supported version of Mozilla. (I don't know which versions are currently supported -- I'm assuming versions before 1.0 are not supported.)

Aside: See BrowserFormattingIssues -- I noticed some discrepancies between the way Konqueror and IE rendered TWiki pages back in the days of Konqueror 1.9.8, and developed some habits to minimize the differences. I should consider checking to see if similar problems exist with Mozilla. I will consider making a test TWiki page (something like the test pages I made once during my C2:WikiEngineReview on C2 for comparing wiki markup languages).



  • In general, Mozilla works fine with TWiki except for some issues in specific versions, and generic issues which apply to all browsers -- see BrowserIssues.
  • Browsers based on Mozilla or its Gecko engine, such as Netscape 6 or higher, or others such as Firefox, K-Meleon or Galeon, should all work identically, depending on the Gecko version they are based on.

Selected Features

Mozilla 1.0 or higher, Mozilla Firefox 0.9 or higher, or Netscape 6.2 or higher, are recommended for TWiki use.

  • Mozilla and Netscape 6+ have the password-remembering and drag-signature features of IE5.x

  • You can use Edit | Find in This Page to search within the text box when you are editing a page (very handy).

  • Some versions of TWiki can cause formatting weirdness in TWiki with non-standard markup entered by the user instead of <NOP> - see MozillaNOPIssues

  • You can install a MozillaSidebar showing recent changes in a 'sidebar' on the left of the browser window

Problem with Proxies

If using proxies:

  • Mozilla 0.9.3 or higher, and Netscape 6.2 or higher, must use HTTP/1.0 with broken proxies, e.g. JunkBuster and some Microsoft proxies, to avoid apparent URL corruption - this is in fact a bug with proxy servers that don't properly implement HTTP/1.1. UrlCorruptionWithMozilla documents how to avoid this problem.

Netscape 6.2 (based on Mozilla 0.9.4)

Netscape 6.2 final should be fine (unlike 6.1), since MozillaBug:86450 (Mozilla drops all space-indentation when you cut and paste in the Edit page) was fixed in Mozilla 0.9.3.

If you are using Netscape 6.1, you should upgrade to Netscape 6.2 or higher to fix a bug preventing file uploads.

Mozilla 0.9.8 (in Mandrake 8.2)

Cursor (Insertion Point) Moves while Editing

Fairly often while editing, the cursor (insertion point) moves unaccountably to some other location in the edit box.

One way to duplicate the behavior is to go to another window and use <ctrl c> to copy some text, then move back to the original window. If you simply press <ctrl v> expecting it to be inserted where the insertion point was when you left the window, you will usually be surprised.

Before I recognized this behavior, I frequently inserted text at the wrong location.

To work around the problem, you can look for the insertion point and then move it to where you want it using the up and down arrow keys and similar.

An easier approach (for me) is to use the mouse to select a word near where you want to work, then use an arrow key to unselect the selection -- the insertion point appears where the arrow key pointed (left, right, up, down).

Strange Behavior with Cut, Copy, and Paste

Cut and Paste behaves somewhat strangely, perhaps only when cutting and pasting to and from a different application. Within a Mozilla text window, I can cut, copy, and paste Ok with either the middle button method (well, I don't know how to cut with that method) or the <ctrl>x,c, and v shortcuts. However, if I copy and paste from another application, things get screwy. (BTW, this is on Mandrake 8.2 from the KDE 2.2? desktop.)

One typical problem -- I select something in another application (highlighting it) and then press <ctrl>c to copy it. When I come back to Mozilla and try <ctrl>v, it doesn't paste what I selected in the other application, but pastes the last selection I made within Mozilla. I should pay attention to Klipper as I do this, and try to get a more precise report of problems, although hopefully this is fixed in the most recent releases of Mozilla and KDE (if that is relevant).

New Vertical Scroll Feature Gets Out of Control

Mozilla has a nice new feature that causes problems at times.

Once you click on the "elevator" on the vertical scroll bar, you can continue to scroll up and down no matter how far off the vertical scroll bar you move (as long as you hold the LMB (left mouse button) down). This is good!

However, sometimes you get stuck in this scrolling mode even if you let the LMB up. This happens most often when you switch to another window and then come back -- I haven't picked up the other key points that are required for this to happen. It's not a big deal to click the mouse somewhere or press escape to kill this scrolling mode, but by the time you realize it, you may have scrolled far away from the original location on the page.

HTML Comments Prevent Saving

Similarly, Mozilla sometimes has trouble with HTML comments (!-- and -- within < ... >). So far I've only experienced the problems on a page which also included an "include" section (i.e., a section surrounded by %STARTINCLUDE% and %STOPINCLUDE% -- not necessarily anywhere near the HTML comments -- on the page Wikilearn.IsLinuxWorthIt the problem occurs if I mark the "rants" section as a comment).

When the problem occurs, I am unable to save the page (preview works, save doesn't).

The next section explains something about HTML comment delimiters, but doesn't explain / resolve the problem of not saving on the Wikilearn.IsLinuxWorthIt page (AFAICT).

Aside on HTML Comment Delimiters

This may belong somewhere else, but I have it on two pages that might be deleted and wanted to save it.

Explanation: Referring to <!-- and --> as the HTML comment delimiters is inaccurate. A more accurate statement is that < and > are the HTML tag delimiters, and !-- and -- are the comment delimiters which work as comment delimiters only within an HTML tag.

I don't entirely blame myself for misinterpreting HTML comment delimiters, because I found several other pages which referred to <!-- and --> as the HTML comment delimiters. Also, IIRC, some browsers showed the problem and some did not.

Mozilla 1.0

The "cannot post large amounts of text"-problem with Mozilla 0.9.9 has been fixed in the 1.0 and higher (for all the affected architectures).

Mozilla 1.1 (Mandrake 9.0)

I still see the following problems:

  • HTML Comments Prevent Saving
  • New Vertical Scroll Feature Gets Out of Control (This still occurs, but not as often as it did with Mandrake 8.2)
  • Strange Behavior with Cut, Copy, and Paste -- I have to reread the previous -- not as bad now (maybe I understand better) but there is a definite distinction that will probably exist for a long time between the clipboard and <something else -- (the selection?)> -- one you manipulate with the mouse buttons, one you manipulate with the <ctrl> c, v, x keys.
  • The other problem (which I thought was on the list but I don't immediately notice) is that in the normal course of events, you can (at least on Mandrake through 9.0) only create one instance of Mozilla (all windows, tabs, etc. use one copy of the code, IIUC) so if any window crashes, all Mozilla windows and tabs disappear
    • I see two reasons for crashing
      • when I open too many windows
      • an unexplained one while navigating the Eryxma site -- it occurs when I surf to a few particular pages even if that is the only open Mozilla window (I'll have to find the specific pages again and list them here) -- those pages work in IE5
    • (I've discussed this somewhere else) but no matter what is done in Mozilla, the possibility of a crash will always exist. All known problems should be fixed, but then something like a Mozilla manager should exist which runs as a separate instance and keeps track of the state (which page is open, scroll and perhaps cursor position, maybe even the edit undo stack) so that after a Mozilla crash you can recover all the previously open tabs and windows. (It should allow some manual intervention to do things like avoiding opening all the (too many) previously open windows/tabs or a specific window/tab suspected of causing the crash.)

I've reported the last item as bugs to Mozilla -- the request to (easily) run more than one instance of Mozilla and the request for a Mozilla manager to help recover from crashes. There apparently is such a thing available as a Java plugin / applet / whatever. The multiple instance request apparently is not mine alone, but depends on some other bugs so I'm not sure when anything will be implemented. This is one of the bugs the multiple instance bug depends on: MozillaBug:135137 .

file:// links don't work

In Mozilla (from at least version 1.4), local file links (using file://) have been considered too insecure to allow. The links appear on the page but when you click on them, nothing happens. The "Error Console" ("Tools" menu) shows errors which indicate that content at this host is not allowed to link or load local files.

Some people (see MozillaDirectLinkBroken) have reported that setting the configuration variable security.checkloaduri (in either your 'all.js' file or in 'about:config') disables this security feature and allows local file links. However, this does not appear to work in Firefox 2.x (see LinkToLocalFileDoesNothing).

To properly secure the use of local file links, it is necessary to edit/create the user.js file in you Mozilla configuration to include the following lines:

user_pref("capability.policy.policynames", "localfilelinks");
user_pref("capability.policy.localfilelinks.sites", "http://sam");
user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");
The 'sites' entry can have multiple servers defined with spaces in between each one.


This lightweight Windows browser works fine as of K-Meleon version 0.7.



Deleted problem of not displaying graphics, it was my EBKAC -- under Tools --> Image Manager, Block Images from this Site was selected. (I selected it?? For six months or so?? Geez!)

-- RandyKramer - 21 Mar 2003

Fixed some typos and added / revised some stuff on HTML comments.

-- RandyKramer - 11 May 2003

Just ran into an oddity with the /twiki/bin/configure script when trying to set the LoginManager on a freshly downloaded Dakar 4.04: The dropdown for selecting the login manager won't respond to the mouse! Figuring it was the browser going wonky, I emptied cache and restarted, but it won't respond to the mouse. Other dropdowns on other pages work.

Keyboarding works: get focus on the dropdown and then hit T on the keyboard. After that, it does respond to the mouse. I figure this is a browser issue, since otherwise somebody would have noticed it. I suppose it could be related to something funky in the page source. I didn't find anything searching for LoginManager config on Support.

Mozilla 1.4.x (various patches) on Linux 2.4 (Originally a SuSE 8.2 distro) with the KDE desktop.

-- FredMorris - 30 Sep 2006

Extended section about local file links (using file://) based on my experiences with same.

-- DuncanKinnear - 11 Mar 2007

I don't understand how to define servers based on this user_pref("capability.policy.localfilelinks.sites", "http://sam");

A better idea is to install LinkToLocalFileDoesNothing 's tip about http://locallink.mozdev.org/installation.html

-- JasonMurdoch - 16 Jul 2007

I am closing this very old question.

-- PeterThoeny - 2011-06-16

Edit | Attach | Watch | Print version | History: r21 < r20 < r19 < r18 < r17 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r21 - 2011-06-16 - PeterThoeny
  • 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-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.