Trying to load that page, Mozilla hangs and takes 100% CPU, but it can easily be killed (-TERM). Frankly, I don't know what a "x-user-defined" charset should look like - but certainly the browser should not die. The site sends a "Content-Type: text/html; charset=x-user-defined" HTTP header. All the other pages linked from Alan Flavell's "Charset Playground" at <http://ppewww.ph.gla.ac.uk/~flavell/charset/playground.html> work without problems (great work!). Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.0.0) Gecko/20020608
with linux build 20020622, it took a while to load the end of the page, but it eventually finished. Also, scrolling performance was very slow. Michael: if you wait long enough, does the page eventually load for you?
WFM, build 2002062109 Win2000
Yes, true - after more than a minute (Athlon 700), it is displayed. I'm sorrythat I didn't wait long enough in the first place.I now also see that this page (and all the other charset testing pages) doesn'tlook like HTML very much: they start with DOCTYPE and "title" tags, but don'thave "html", "head" and "body". This is strange - all the other pages on thatsite look very well, and Mr. Flavell certainly knows how to write valid HTML.But, alas, this doesn't seem to be the source of the problem. I added theappropriate html/head/body tags (tidy still throws out a lot of warnings, but noerrors) and put the page on my local Apache. As soon as I serve the page with"charset=x-user-defined", Mozilla shows that slow behaviour. With"charset=x-dontknow", Mozilla has not the slightest problem.
wfm using build 2002062208 on Win2k (trunk).
Updating summary. I would say that the speed is unacceptably low, but I'm not aware if "x-user-defined" requires mozilla to do some ourageous calculations or something. I'll confirm the bug, and then the owner can WONTFIX it if this is "just the way it is." Oliver: WFM --- does that mean the page loads reasonable fast in Windows2000? Doesn't this belong to Layout?
Michael: yes, I could load page in 2 or 3 seconds.
I don't want to spread false assumptions about HTML: as Alan Flavell told me, the "html", "head", "body" tags are all optional, and the page is valid according to WDG's validator, see <http://www.w3.org/TR/1998/REC-html40-19980424/struct/global.html#h-7.3>. This problem might as well be the X server's fault (XFree 4.1.0 here) - although Opera 6.01 has no problem displaying that page. Mozilla apparently uses at least two different-looking fonts for the table on that page, Opera does not.
Mozilla-0.9.9 on the same machine/X-server displays that page without problems. With 1.0.0, the rendering of the page changes from one loading to the next and even when the page is repainted because it got obscured by another window. I uploaded a few screenshots (of Mozilla-1.0.0) to <http://home.t-online.de/home/michael.mauch/mozilla/>.
Can reproduce this on 06-24 branch build / linux RH7.2.
see also bug 156882
It could be that the font search code finds chars that are not in any font so it is searching *every* font for *each* of these chars *each* time it sees them. If this is true then one possible solution would be to add a dummy font (perhaps as the 2nd font). Whenever the font search code finds a char is not supported mark ccmap of the dummy font as supporting that char. This would allow the subsequent searches to stop quickly rather than re-searching all fonts.
*** This bug has been marked as a duplicate of 147222 ***
Verified as dup, please re-open if disagree.