66995 - Character Coding falls back when Content-Type sets charset

Status: VERIFIED DUPLICATE of bug 53140

(Core :: Internationalization, defect)

Description

[Balazs Nagy]

When I check View/Character Coding/Western (iso-8859-1) when Content-Type is set
to "iso-8859-2," it reloads the page then falls back to Central European
(iso-8859-2).

Comment 1

[Asa Dotzler [:asa]]

updating component

Comment 2

[nhottanscp]

Content-Type charset from the server is iso-8859-2.
Charset override does not work for that case.
I do not know if that's a feature or a bug, reassign to ftang, cc to momoi.


http://webtools.mozilla.org/web-sniffer/view.cgi?url=http%3A%2F%2Fwww.geekfinder.hu%2F

Comment 3

[Katsuhiko Momoi]

Balazs, I used a build from 1/29/2001 and loaded
the page you mention. My connection is DSL or better speed.
And under his condition, I did not notice any reloading. 
I wonder if the effect of reloading is noticeable on a
modem connection but not so on a fast connection like
mine.

Questions to ask are:

1. Can it be made to start loading with the content-type charset
   from the beginning? --> This seems unlikely. How can we even 
   know what charser is sent from the server without parsing
   the content?

2. I think we always assume the content to be in the current 
   default charset and then reload if necessary as parsing 
   continues.

If 2 is true, then it would be hard not to realod if the default the
user selected is not the same as the charset sent from the server.

I tend to think that the current behavior is accodring to the
spec. Maybe ftang can think of some ways to improve this.

Comment 4

[Balazs Nagy]

Heh.  It's my site and I can load from localhost either.  BTW load means
re-rendering (it have to be reloaded from cache.)

I did another test (it's my site, after all), and I put out the
'charset=iso-8859-2' entry from Content-Type header, and now I can switch among
Character Codings.

Eg. the header and META tags are handled differently.

Comment 5

[Balazs Nagy]

Heh.  It's my site and I can load from localhost either.  BTW load means
re-rendering (it have to be reloaded from cache.)

I did another test (it's my site, after all), and I put out the
'charset=iso-8859-2' entry from Content-Type header, and now I can switch among
Character Codings.

Eg. the header and META tags are handled differently.

Comment 6

[Katsuhiko Momoi]

I'm sorry I misunderstood the original report.
The original problem seems to be that,

When you try to switch to an encoding, e.g. ISO-8859-1, after
the page has loaded with the charset sent from the server
different, e.g. ISO-8859-2, then the manual override 
is not effective and instead falls back to the server
charset.

If this description is correct, this is a bug.
Our spec calls for the ability to override the
Content-type charset header from the server.
Otherwise, howe can the user ever override
incorrect charset info from a server?

I noticed that there seem to be other things wrong with 
the charset menu behavior with the latest daily build.
Please test the Character Coding menu carefully with
the latest truk build.

Comment 7

[nhottanscp]

*** This bug has been marked as a duplicate of 53140 ***

Comment 8

[Teruko Kobayashi]

Verified as dup.