Mozilla load and scrolls pages with charset=x-user-defined very slowly.

VERIFIED DUPLICATE of bug 147222

Status

()

Core
Internationalization
--
minor
VERIFIED DUPLICATE of bug 147222
16 years ago
15 years ago

People

(Reporter: Michael Mauch, Assigned: Shanjian Li)

Tracking

({intl})

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

16 years ago
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

Comment 1

16 years ago
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?

Comment 2

16 years ago
WFM, build 2002062109 Win2000
(Reporter)

Comment 3

16 years ago
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.

Comment 4

16 years ago
wfm using build 2002062208 on Win2k (trunk).

Comment 5

16 years ago
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?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Mozilla hangs on page with charset=x-user-defined → Mozilla load and scrolls pages with charset=x-user-defined very slowly.

Comment 6

16 years ago
Michael: yes, I could load page in 2 or 3 seconds.
(Reporter)

Comment 7

16 years ago
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.
(Reporter)

Comment 8

16 years ago
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/>.

Updated

16 years ago
Keywords: intl
QA Contact: ruixu → ylong

Comment 9

16 years ago
Can reproduce this on 06-24 branch build / linux RH7.2.

Comment 10

16 years ago
->charset owner.
Assignee: yokoyama → shanjian
(Assignee)

Comment 11

16 years ago
accepting. 
Status: NEW → ASSIGNED

Comment 12

16 years ago
see also bug 156882

Comment 13

15 years ago
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.

Comment 14

15 years ago

*** This bug has been marked as a duplicate of 147222 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE

Comment 15

15 years ago
Verified as dup, please re-open if disagree.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.