Donald Knuth wrote
Beware of bugs in the above code; I have only proved it correct, not tried it.
Except if otherwise stated, these bugs were found or confirmed in full-release (but not necessarily now current) browser versions, using Windows XP sp3 on Intel P4/3GHz.
Text layout bugs likely to affect form or table layout are included.
For some ways of reporting bugs, see "Browser Bug Reporting" in On Reading Web Pages.
For details of my current browser versions, see js-datex.
This is certainly not a complete list; it just includes bugs that I have discovered or investigated. I use some browsers more than others.
These bugs are also expected to appear, where applicable, when using Windows Script Host (WSH) for JScript and VBScript, because of shared library files.
Date Troubles : Automated Script Tests, line Z ; ISO Week Number Using DatePart; it is wrong for three days per 28 years plus one day per 400 years.
Opera 11.00, crash out, first found in Test a Reader-Provided Function when using More algorithms for Easter Sunday as Day-of-March, second function IanTaylorEasterJscr(YR), with executable code after an unconditional return, as described within that function. Still crashed in Opera 11.01, 11.10, 11.11, 11.50, 11.51, 11.52, 11.60, 11.61, 11.62, 11.64, all running in WinXP pro sp3 and reported. For some of those versions, seen also on a laptop with WinXP pro sp3.
No such crash seen in IE, Firefox, Opera 12.00, Safari, Chrome.
This is a simplified demonstration version.
Strings (generally representing functions) display incorrectly in a popped window. Tests are below, at Old Opera PopBtn. Fixed in Opera 11.10, it seems.
Except for ∓, the above work properly in Opera 11.50; but ∓ did work in 11.11.
This is actually a difficulty caused by the font that Opera chooses for the offending characters, and likely to be system-dependent. See Unexpected Font Height below.
Cannot read selected text in a readonly textarea, in 5.0.3 and 5.0.4.
Safari 5.0.5 gives 31. See Safari new Date(String).
Could not read selected text in a readonly textarea, in 8.0. Can do so in 10.0.
Fails to access content of an iFrame when page and content are local.
Browsers have varied in what RegExp \s matches.
Number.toString() is bad for unpopular bases in some browsers - for details and test code, see Testing .toString(radix)
For investigation :-
There is a problem with writing \n, \t, \x09, but not <br>, into PRE, seen in my MS IE 8 but not in my other browsers. :-
Reported 2004-07-17 GMT in "JScript v5.6.8513, Windows Script Host v5.6."; then seen by me in MSIE4 "JScript 3.1.2124" and in MSIE6 "JScript 5.6.8831", presented more simply :-
A fairly long fixed-point input number String, but not a fairly long integer, is misconverted to Number in MSIE 4 to 8, but not in Firefox 2/3, Opera 9, Safari 3/4, or Chrome 3.
The error also appears in parseFloat() and Number().
The following script on this page generates the good display and the test buttons.
Simpler code showing error in my Opera 10.63 and 11.01. The test string is obtained from the textarea above if not empty, otherwise computed. The popped contents should match what appears next.
There appears to be some internal addressing error in the browser.
See also in Testing With Random Numbers.
This uses any simple algorithm to generate test cases reproducibly - but I may change the defaults.
The ECMA 262 specification of .toString(radix) is weak. One would expect the method to behave, for integers and non-integers, in exactly the same manner as .toString() except as required by the difference in radix. Therefore, it ought to give as many fractional digits as are significant, with trailing zeroes then removed. For all combinations of Number and radix, all browsers ought to give the same strings.
That does not currently (June 2010 or later) happen cross-browser for all radixes.
The default fonts should all be 14pt serif, which may not matter much (but, as far as I have seen, only Family Serif shows the fault).
In my Windows XP sp3 system, when using Firefox 3.6.13, Opera 10.63, Opera 11.01, but not in much older Firefox or in Firefox 5.0 and not in Opera 11.00 or 11.50, the middle rows in the first table are about three times taller than they should be, caused by the special characters therein, "therefore" and "minus-over-plus".
In MS IE 8, Safari 5.0 3, Chrome 9.0, all table rows appear the same height, as they should; but in IE8 the offending characters are not drawn.
The blue-bordered boxes show that characters are stretched without being in a table; and that they do not stretch in monospace.
In my Opera 11.50, the glyph for ∓ may be slightly too tall. Opera 11.60 also shows faults.
Many characters in Entities for Symbols and Greek Letters showed the problem in Firefox 3, but do not in Firefox 5.0.
This may all be due to "font substitution" using glyphs from "Cambria Math", which, in the WordPad font selection dialogue of my WinXP sp3 + MSOffice machine, shows a very high baseline. But a browser should not let it happen.
See Jukka K Korpela's Line spacing problems for a proper explanation.
Each of these tests has in the past either shown a problem in at least one of the browsers or shown a difference between browsers. Entries in the "Yours" column are computed by your browser using function AutoTest. Other columns do not necessarily refer to the latest Windows browser release. Some of the more important results are colour-coded. Opera 10.61 was much better than Opera 10.10.
A darker yellow shows those values given by your current browser which do not exactly match the "ECMA" column.
|A||\s matches \u2029||false||true||true||true||true||true||true|
|F||Long numbers (see source)||10||1||1||1||1||1||1|
|G||parseInt("09")||0||9||0||9, 0||0||0||9 ?|
|J||Math.round (see source)||1||1||0||1||0||0||0|
|‡ : see corresponding Note below.|
A similar table for date-related flaws is at Automated Date Tests.
|MS IE 8||2203|