43529 - Propagate charset override in frames

Status: VERIFIED FIXED

(Core :: Internationalization, defect, P3)

Comment 1

[cata]

Yeah, the forced, override charset should affect all frames, not only the top 
level one.

Comment 2

[cata]

*** Bug 44827 has been marked as a duplicate of this bug. ***

Comment 3

[Frank Tang]

Mark it fix, I can no longer reproduce 44827

Comment 4

[Teruko Kobayashi]

This does not work in 2000-10-30 MN6 Mac, Win32, and Linux build.  Reopening.

Comment 5

[Teruko Kobayashi]

Added intl and nsbeta1 keywords.

Comment 6

[Frank Tang]

clear M17

Comment 7

[Frank Tang]

move all cata's bug to ftang

Comment 8

[Frank Tang]

teruko- any test case we can use? please put the link here.

Comment 9

[Frank Tang]

mark it as moz0.91

Comment 10

[Frank Tang]

shanjian- can you take a look at this ?

Comment 11

[Teruko Kobayashi]

Changed QA contact to [e-mail].
I put the test cases in the URL.

Comment 12

[nhottanscp]

*** Bug 70768 has been marked as a duplicate of this bug. ***

Comment 13

[Shanjian Li]

Attachment: proposed patch.

Comment 14

[Shanjian Li]

the parent's charset could not passed to child because the charset
from cache has higher priority. That caused this problem. I adjust 
the priority of the two. 

Comment 15

[Frank Tang]

looks reasonable. r=ftang

Comment 16

[Erik van der Poel]

I guess this patch would fix the immediate problem, but the design of that part
of the product isn't very good. When the user overrides the charset, that
override should be passed down to all child frames. So it really should be
using something like kCharsetFromUserForced instead of ParentFrame.

sr=[e-mail] for now, but we should probably create a new bug report
for the issue I mentioned above.

Comment 17

[Shanjian Li]

*** Bug 66130 has been marked as a duplicate of this bug. ***

Comment 18

[Shanjian Li]

After this bug is resolved, Please verify 66130 as well. If it still happens, please reopen that bug.

Comment 19

[Shanjian Li]

fix checked in.

Comment 20

[Shanjian Li]

(answer erik's question)
Charset from parent frame should be remain as charset from parent frame no matter 
if this charset is user-forced to parent frame. The reason is that parent
frame might have difference charset from its children. We might implement something 
in future to let user override charset setting for child frame only.

Comment 21

[Yuying Long]

Base on the 4 testcases in:
http://babel/tests/Browser/charoverride/charoverride.html
It seems the test results doesn't follow the description.

Here is the results(04-30 trunk build on Win2k-CN) that are different than the 
actual result in testcase:
case 1:  http://babel/tests/browser/charoverride/framewnochar1.html
Only Auto-Detect(off) | EUC-JP can display correctly.
case 2: http://babel/tests/browser/charoverride/framewnochar2.html
Only Auto-Detect Japanese can display correctly but EUC-JP has been marked in 
charset menu.
case 3:  http://babel/tests/browser/charoverride/framewchar1.html
This one seems work fine.
case 4:  http://babel/tests/browser/charoverride/framewchar2.html
When Auto-Detect(off), no matter how you change the charset 
(e.g. iso-8859-2, Shift-JIS, EUC-JP, EUC-KR) will get a display correctly page.

bug 66130 has a similar result as case 4, I'll add comments there too.

I'll re-open this bug.

Comment 22

[kill this account]

I've been considering charset as part of the embedding api work and
I wondering if having the parent's charset override the cache value
is really correct.

Shouldn't a charset *override* command be propagated thru the child frames 
instead propagating the parent's charset?

And once a document's charset is set via an override shouldn't that value
(now in cache) be used until a new override is set or a super-reload clears
the override?

Comment 23

[kill this account]

looking at the code I don't see the override being propogated:

http://lxr.mozilla.org/seamonkey/source/intl/chardet/src/nsDocumentCharsetInfo.c
pp#45

as the default charset is 

http://lxr.mozilla.org/seamonkey/source/content/base/src/nsDocumentViewer.cpp#46
45

Comment 24

[Frank Tang]

what is the status? any test cases (procedure) that we can verify this is fixed 
or not ?

Comment 25

[Marek Z. Jeziorek]

TM to 0.9.2 per PDT triage (it's OK to check it in by Friday or after 0.9.1
branch is made).

Comment 26

[Shanjian Li]

I verified all testcases on my local machine (source tree updated this morning). I believe 
this is fix. Previous failure was most likely caused by other problem. I saw the problem
several days ago but it dissappeared these days. I guess it got fixed. 

Comment 27

[marina]

qa contact=marina

Comment 28

[marina]

using Kat's charsetoverride test cases i was verifying this bug and in case # 5
where the first frame has a wrong meta tag and could be corrected by overriding
it with the right one ( Shift-Jis) or Autodetect should work it is NOT
happening. I am reopening

Comment 29

[marina]

using Kat's charsetoverride test cases i was verifying this bug and in case # 5
where the first frame has a wrong meta tag and could be corrected by overriding
it with the right one ( Shift-Jis) or Autodetect should work it is NOT
happening. I am reopening

Comment 30

[Shanjian Li]

Kat's testcase need to be updated. For any frame, the priority order is :
(partially) meta tag, autodetection, parent frame. That means that if 
meta tag charset exist, we will ignore autodetection and charset passed 
from parent frame. 

Comment 31

[marina]

with that in mind ( if meta tag charset exist, we will ignore autodetection and
charset passed from parent frame) i 'll verify it as fixed, because it was the
only case where it wasn't possible to override the meta tag... 

Comment 32

[marina]

with that in mind ( if meta tag charset exist, we will ignore autodetection and
charset passed from parent frame) i 'll verify it as fixed, because it was the
only case where it wasn't possible to override the meta tag... 

Comment 33

[Roy Yokoyama]

marina: can you verify this?  I am getting number of bugs ( eg 112112 ) about this.

REOPENING; but if it's working for you then please mark it as WORKSFORME

Comment 34

[Eugene Savitsky]

I discovered that this does not work only with KOI8-R (KOI8-U is OK).

Look at 112112 for more info.

Comment 35

[marina]

Eugene, in bug 112112 you are setting the default charset to Koi8-r to view the
page that has meta tag " Cyrillic 1251", i don't understand how you expect it to
display correctly, with default set to 1251 in Pref the page displays correctly,
then "Show only this frame" will be correct as well and if you look at the
source of the frame you'll see the meta tag "charset=cyrillic-1251"

Comment 36

[Shanjian Li]

after bug 112793 was fixed, override charset in framed webpage will 
populate the charset setting from parent to children. I don't see 
new problem in any comment. resolve this is fix. 

Comment 37

[Eugene Savitsky]

I reopen. See bug 112112 for testcase.

Comment 38

[marina]

i tested this bug with test case in 112112, here are the steps you suggested: 

<1. Load the http://www.f1-racing.ru. It is not in cyrrilic. 
<2. Now set KOI8-R in View -> Character Coding. All looks fine.
(well it doesn't , it is gibberish)
<3. Reload the page.
<4. Again it is crap.
<5. But the coding in View -> Character is KOI8-R!
<6. Just press again KOI8-R and you can again read as it should.
( this didn't help either)

When i set the default to Koi8-r i wasn't able to view the page neithher in
frame nor after i reload. But , when the default charset in Prefrs
(Pref|Navigator|Languages) is set to Cyrillic 1251 (not to Koi8-r) then there is
no problem to view the  page neither the frame. 
Same results with your second test case for an estonian page, if you set the
default to Cyrillic-1251 and type "test" it'll show up in the right frame
correctly in russian, the rest of the page is also displaying fine.
I am using 2002-01-03 build

Comment 39

[Eugene Savitsky]

Marina, please read my instructions one more time. You must set Preferences ->
Navigator -> Languages -> Default Chacter Set to KOI8-R. Only then you will see
this behavior.

1. Set Preferences -> Navigator -> Languages -> Default Chacter Set to KOI-8.
2. Load http://www.f1-racing.ru (it does not displays correctly)
3. But when you press View -> Chacter Coding -> KOI8-R all looks fine (even when
a mark is allready on the KOI8-R you press it and all looks fine).

Also with the second test:

When you time latin - all is ok, but just write in the field "test" in russian
and you'll see the bug again.

This happens only when Preferences -> Navigator -> Languages -> Default Chacter
Set is set to KOI8-R. KOI8-U works also fine.

Comment 40

[marina]

Eugene, in my comments to your test case i've said that with the default set in
Prefs to Koi8-r i see this behavior (garbage display), i do not see it when the
default is set to Cyrillic-1251 or Western. In that sense we do not disagree.
All i am saying is that it looks like you are trying to view a frame in Koi8-r
whereas the parent page  probably was in 1251 which is propagated. The test case
#2 (estonian translation) explicitly has a meta tag "charset=cyrillic-1251". 

Comment 41

[Eugene Savitsky]

Marina, please excuse me - my english is not so good. :(

Yep, you right, all pages uses Win-1251. 
But I'm able to see http://www.f1-racing.ru when I set to KOI8-R in the Edit
menu... Do you?

Comment 42

[marina]

Eugene, first of all: your english is great!!!
and yes, i was able to view the page correctly if i set up the default in prefs
to koi8-r on the second attempt... But i am thinking that this is maybe because
i already viewd this page in cyrillic and the cached charset has a priority..?
cc'ing shanjian and roy.

Comment 43

[Shanjian Li]

eugene, marina,
Would you mind if I suggest to continue all the discussion in bug 112112? 

Comment 44

[marina]

I don't! Then what would be the resolution for this one? Thanks.

Comment 45

[Shanjian Li]

If you think this bug and bug 112112 are 2 different problems, that's fine. 
But let's fix 112112 first. We can keep this one open until bug 112112 is 
fixed. Then we will have a better idea about if they are different problems,
or duplicates, or whatsoever. 

Comment 46

[marina]

No, i think this bug is fixed...and i would guess that the problem reported in
112112 is an expected behavior, but correct me if i am wrong.

Comment 47

[Shanjian Li]

Mark this as fix. 

Comment 48

[marina]

verifying as fixed. Eugene, the problem of the default encoding and page display
in frame will be examine in bug 112112.