Browser issues with MediaWiki


 * ''For up to content, see the Compatibility matrix for browsers

See also: Wikipedia:Browser notes

This page is intended to document problems with certain web browsers in editing Wikipedia articles. If you have experiences with a specific web browser, please add them here.

Some of these problems may be bugs, some of them may be user interface annoyances, and some of them may result from incorrect or unexpected implementation of certain features on the Wikipedia site. If you find bugs in your browser, this is not the place to report them, but if they are relevant to Wikipedia, they may as well be listed here.

IE on MacOS 9
Internet Explorer 5 on Mac OS 9 (discontinued and obsolete) displays Wikimedia pages badly, especially quotes.

Firefox 9. doesn't display pages correctly (or at least as intended). The nav, search and toolbox elements are moved out of sight to the bottom of the page. Mediawiki 1.15.1. This site has further discussion and possible solutions.

Problems with saving
Internet Explorer 6 deletes any page longer than 32k when saving.

Problems with editing
When editing, Firefox 2.x changes all non-breakable spaces (code 0xA0) to breakable spaces (code 0x20). This can lead to ugly-looking diff pages. Bugzilla entry. Fixed in 3.0+ versions.

Netscape 4.7/Windows 98 Occasionally refuses to allow insertion into longer articles.

Internet Explorer 5/Mac OS X (and perhaps older?) Textarea seems to be limited to about 32k; text cannot be inserted into longer pages, instead met with an indignant beep.

K-meleon (Mozilla)/Windows 95 Unicode characters replaced by '?'.
 * This happens on any browser that doesn't support unicode.

Note: 32kb limits Textarea was limited to 32kb in both Netscape 3 and MSIE 3, presumably on all platforms for which those browsers were respectively available. In neither case does the browser warn of a buffer overflow. (I am not sure about the version 4 browsers - an experiment might be needed)

Character encoding
All Wikimedia wikis are now encoded as Unicode UTF-8 so that they can cleanly include pages and commentary in any language. (Actual display of any given language's characters depends on the fonts installed on your computer, of course!)

Note that some browsers have poor Unicode support and may, in addition to not displaying properly, damage non-ASCII characters during editing. Known problems include:
 * Opera 5.0 for Macintosh, and probably other OSs as well. (Opera 6.0 does have Unicode support; if you've used it please say if it works!)
 * Opera 6.04 for Windows works well. -- PE 21:50 Nov 15, 2002 (UTC)
 * Netscape 4.x
 * IE 5.0 (Mac)

Browsers known to be able to view and edit correctly include:
 * Mozilla and Mozilla-based browsers (ex Netscape 6 and higher)
 * IE 5.5 (Win)

And with appropriate configuration:
 * Lynx if Unicode UTF-8 character set is selected in options. Proper display may require setting your terminal for Unicode.
 * Links if in graphics mode

I am having a problem editing. When I click on Edit, the article appears without the references, links, HTML. When I make minor changes, all the links and references are lost. This happens with all browsers (Internet Explorer, Firefox and Chrome). chroe worked very briefly. Am running Windows 8.1. 2601:4:4D80:5C7:143F:CAC9:517E:7050 19:30, 21 December 2013 (UTC)

Display problem
My contribution to Wikipedia:Wikipedia_talk:WikiProject Grammar title Display problems with this project page may be relevant here, regarding a possible Mozilla bug.

Displaying MathML
Few browsers support MathML, and MediaWiki still consider it as an experimental feature. Anyway W3C publishes a list of browsers and of browser plugins and extensions supporting MathML (with relative bugs).

Language support
There are issues with supporting languages like Lingala. It turns out that at this time Safari provides the best language support. Firefox and Chrome come second and third they show the content properly but not in the edit mode. Internet Explorer did a real poor job in the edit mode showing a character that was not selected. GerardM 02:27, 19 December 2008 (UTC)

Issues when following links with IE 7.0
When opening some articles on http://en.wikipedia.org/, a browser pop-up appears indicating:

File download - Security warning Do you want to save this file or find a program online to open it? Name: Wikipedia_Browser_notes Type: Unknown File Type, 20.4 KB From: en.wikipedia.org

[Find] [Save] [Cancel]

After clicking "Find" the following details appear:

Windows has the following information about this MIME type. This page will help you find software needed to open your file. Windows File Association MIME Type: application/x-gzip-compressed Description: UnKnown Windows does not recognize this MIME type.

Meanwhile, most of the articles in Wikipedia open correctly. Only a few seemingly random files do not open properly.

Some people experiencing this problem have found that the solution to this problem is simply to register with Wikipedia. After creating an account and logging into the site, the problem seems to disappear entirely. This is an easy way to deal with the problem and suggests that the root cause might somehow involve cookies. [speculation] Others have reported that uninstalling the Google Desktop seems to have fixed this problem.

Something else that caught my attention, notice how browser notes have the icon for external sites, and talk colon does not:

w:en:Wikipedia:Browser_notes

w:en:Talk:Colon_(punctuation)

--82.1.151.22 16:21, 17 May 2009 (UTC)

Symptom details
When logging in to our MediaWiki some users get:

Most users simply specify a URL of http://wiki, and this works without problem. Some users specify a fully qualified host name (FDQN) of http://wiki.our_ad.InternalDomain. These users experience the problem when using Internet Explorer 9. The problem does not occur when using Firefox or Chrome.

Cause
Internet Explorer does not seem to like an underscore in the host name. Although the use of underscore is permissible, RFC 1034 advises against it. Various web sites report this problem on IE 7, 8 and 9. A network trace of the problem shows that IE POSTs the login details to the correct address but there are no cookies in the POST HTTP message or subsequent HTTP method requests.